Sie sind auf Seite 1von 11

Java Midterm Review Sheet

(Shamelessly ripped from Head First Java, Daves Slides, and some kid who I
mugged for his Java notessorry Vikas, that was me.)
I.

Java Basics Needed to get started


a. Code Structure:
i. Source File holds one class definition. A class represents a piece of
a program.
ii. A class has one or more methods. A class is a blueprint for an
object.
iii. A method contains instructions for how that method should be
performed.
b. Variables
i. Variables hold primitives and references. Primitives are basic
building blocks of programs. References are remote controls that
allow you to access objects.
ii. Variables must have a type (ArrayList, int, etc.) and a name.
iii. Instance variables are declared inside a class but not within a
method. They are given default values if these values are not
explicitly set:
1. integers get set to 0
2. doubles and floats go to 0.0
3. booleans get set to false
4. references get set to null
iv. Local variables are declared in a method, and must be initialized
before use. (They DO NOT get a default value)
v. Local variables live only within the method that declared the
variable. Instance variables live as long as the object does. If the
object is still in memory, so are its instance variables.
vi. If no reference variable is pointing to an object, that object is
eligible for garbage collection.
vii. Heres something to make you dizzy: If an instance variable
belongs to an object that is referenced only by a local variable,
then it will be destroyed when the method is done being executed.

II.

Classes, Objects, Methods, oh my!


a. All java code is defined in a class.
b. A class is a blueprint for an object. It tells the virtual machine how to
make an object from that particular type.
c. An object knows things and does things. A user (rather than the designer)
of an object does not need to know *how* an object works.
d. Things an object knows about itself are called instance variables these
represent the state of the object.
e. Things an object does are called methods. They represent the behavior of
an object.

f. A class can inherit instance variables and methods from a superclass.


III.

Deeper look into Methods


a. A method uses formal parameters. A caller of the method passes actual
parameters or arguments. When you pass in arguments, their values are
set to the parameters which are local variables used by the method.
So, what the heck does that mean?
int addOne(int a){
a = a+1;
return a;
}
int a is a parameter. So if I call the method with an integer variable
numOne which is equal to 1 like so:
int b = addOne(numOne);
Then numOne, the argument the caller passes in, is set equal to a, and the
method returns a+1 which, in this case, is 2.
Note that numOne is still equal to 1. IT DOES NOT CHANGE.
But, it will if I do this:
int numOne = addOne(numOne);
Note, I can also do this addOne(14) and get 15 back.
THEN numOne changes, but not because it was passed into the method. It
was because I was changing the variable via the assignment operator the =
sign.
b. Methods can use instance variables so that objects of the same type can
behave differently.
c. A method can have parameters, which means you can pass one or more
values in to the method.
d. A method must have a return type. A void return type means that method
doesnt return anything.
e. If a method declares a non-void return type, it must return a value
compatible with the declared return type. You can return anything that can
be implicitly promoted to that type. For numerical values, this means you
can return something that can fit into the return type. (If the return type is
double, you can return an int. If its an int, you can return a byte. BUT if
the return type is an int, you cannot return a double without explicitly
casting it.)

f. You can ignore return values:


addOne(5);
is fine, you are not doing anything with the return value of 6.
IV.

Constructors
a. Code that runs when you say new to a class type an object of that type is
created using the class as a blueprint.
b. Constructors initialize the state of an object
c. In you dont specify a constructor, the compiler will put one in for you
d. If you put a constructor in your class, a default constructor will not be
provided by the compiler.
This could be a problem, because Java calls the constructors of the
superclasses, going up the inheritance hierarchy. If there is no default
constructor, the constructor chain is broken:
class Person {
String name;
Person (String name) { this.name = name; }
}
class Student extends Person {
private boolean suckUpToTA;
Student( ) {
// here Java tries to call new Person() but cannot find it;
suckUpToTA = true;
}
}
How do we fix it?
class Student extends Person {
private boolean suckUpToTA;
Student( ) {
super(name); // this has to be the first thing in constructor!
suckUpToTA = true;
}
}

e. A constructor must have the return type of the class.


f. You can have more than one constructor in the class, as long as the
parameters are different. Having more than one constructor in class is an
example of overloading.
g. All the constructors in an objects inheritance tree must run when you
make a new object. Thus, by default the compiler adds a call to the
superclass constructor (A PARENT MUST EXIST BEFORE A CHILD) if
no call is specified:
If you have:
public Mini extends Moni(Color c){
//other code
}
The compiler makes it:
public Mini extends Moni(Color c){
super();
//other code
}
h. You can add a call super(); yourself, SO LONG AS ITS THE FIRST
THING YOU DO!
This is bad:
public Mini extends Moni(Color c){
//other code
super();
}
i. If you want to use a superclass constructor with arguments, you can pass
parameters into the call to super.
public Mini extends Moni(Color c){
super(11);
//other code
}

j. If you want to call a different constructor, call it using this() or


this(parameters) as so:
public Mini extends Moni(Color c){
this(11);
//other code
}
Note that it must be the first thing in the constructor, and a this() call can only
be made in a constructor.
k. YOU CAN MAKE CALLS to another constructor via this() (or this(0) or
this(false) or whatever other constructor you have made) OR you can make a
call to a superclass constructor (like super() or super(0) or super(WHAT THE
HELL IS JAVADOC??) )
V.

Polymorphism (Polly More Fizz m)


a. The subclass inherits from the superclass. The subclass extends the
superclass.
b. A subclass can override methods it inherits from the superclass. Instance
variables are not overridden, their values can be changed by the subclass.
c. EXAMPLE:

Doctor is the superclass, Surgeon and Family Doctor are subclasses.

The treatPatient() method is overridden in the Surgeon class.


The Surgeon class adds the method makeIncision().
The FamilyDoctor class has a new instance variable makesHouseCalls.
Adds a new method, giveAdvice().
Surgeon has 1 instance variable, worksAtHospital, inherited from Doctor
FamilyDoctor has 2 instance variables, one inherited and one of its own.
Surgeon has 2 methods, Family doctor has 2 as well.
FamilyDoctor can treatPatient() but CANNOT makeIncision(). The latter
method belongs to another subclass.
d. A class with private constructors it cant be subclassed. (this is one way to
break the constructor chain discussed above)
e. A package class can be subclassed only by classes in the same package. A
protected class can be subclassed anywhere.
f. Overloading
i. An overloaded method is a different method that happens to have
the same name but different parameter types.
ii. Rules:
1. Return types can be different
2. You cant change only the return type
3. You can vary access level in any direction.
g. Overriding
i. if you want to change the behavior of a method, but dont have
access or permission to change to the source code, you can extend
the class and override the method.
ii. For overriding, a method is a contract. Arguments must be the
same, return types must be compatible. Compatible means that you
can return a smaller sized numerical value or a subclass. The
reason for the latter is that a subclass is guaranteed to do anything
its parent class can do. THE OPPOSITE IS NOT TRUE. An
animal reference is not guaranteed to swim, so you cannot return a
reference of type Animal if you are supposed to return an object of
type Fish.
iii. A method cant be less accessible.
h. THE ULTIMATE SUPERCLASS: OBJECT (DUN DUN DUN!)
i. Any class that doesnt explicitly extend another class, implicitly
extends Object.
ii. Object contains some specific methods, such as equals(Object o)
and toString();

iii. When overriding methods from Object, follow the rules. You
HAVE to pass in a parameter of type Object, you HAVE to keep it
public if it was before. You HAVE to return a compatible object.
iv. An object contains everything it inherits from each of its
superclasses:

If you look at the rectangles as remote controls, note that Object


cannot do Animal behaviors and Animal cannot do Cat behaviors.
But the Cat can do Animal behaviors AND Object behaviors.
So the following would lead to errors:

Object a = new Animal() is fine, but a.eat() is not.


Animal b = new Cat() is fine, but b.scratch() is not.
Animal b = new Object() is wrong.
Cat c = new Object() is wrong.
Cat c = new Animal() is wrong.
But I can *cast*, where appropriate, to access the methods:
//This good
Object o = new Animal();
Animal annie = (Animal) o;
annie.makeNoise();
//This bad
Object o = new Animal();
Cat annie = (Cat) o;
annie .makeNoise();
*NOT ON MIDTERM: But what if I have a Tiger class that extends
takeOverWorld, and YET there comes a time when I want to use the base
class takeOverWorld method?
Use super.takeOverWorld() within the Tiger class:
Class Tiger extends Cat {
void takeOverWorld(){
super.takeOverWorld();
//then you can do subclass stuff
}
}
i.

Interfaces
i. A 100% abstract class.
ii. Allows for multiple inheritance by allowing a class to extend one
superclass but implement multiple interfaces.
iii. A class that implements an interface must implement all the
methods of the interface, since all interface methods are implicitly
public and abstract. You can explicitly write that a method is
public and abstract but you dont have to.
j. IS-A vs. HAS-A: IS-A relationships are examples where inheritance
should be used, HAS-A relationships are examples where composition
should be used.
i. A triangle IS-A shape, a cat IS-A feline, and a surgeon IS-A doctor

ii. A tub is not a Bathroom, a bathroom HAS-A tub! A wizard is not a


fancy hat, a wizard HAS-A fancy hat.
iii. IS-A only works in one direction. A wolf IS-A animal makes sense,
but an animal IS-A wolf DOES NOT.
iv. instanceof checks to see an argument either plays the role of an
interface or extends a class.
Example:
If we have Class B extend Class A and implement interface
C, and instantiate an object b of type B, then the following
will return true:
1. b instanceof A
2. b instanceof C
v. What does inheritance buy you?
1. You avoid duplicate code
2. You can write flexible code:
a. Animal myPet = new Pet() will allow you to use
any of the methods defined in the Animal class, but
you CANNOT use the myDog reference to call
methods specific to the Dog class.
b. A method that has a parameter of the Animal type
can take in any subclass of animal.
3. You define a common protocol for a group of classes
a. If you have an Animal class with methods
makeNoise(), eat(), sleep(), and roam(), then all
animals can do these things but not always in the
same way.
VI.

Exceptions (Risky Business who was Tom Cruises costar?)


a. Used to handle risky code code you CANT guarantee will work at
runtime.
b. Use try-catch you try to do something, and catch the problem you expect
to occur.
c. if a method throws an exception, it must tell us about it in its signature:
public void takeRisk() throws Exception{
// risky business
}
d.
e.
f.
g.

Catch is where you try to recover from something bad that happened.
A method throws exceptions when something fails at runtime.
An exception is an Object!
This is how you throw an exception:
throw new Exception();

h. The finally block is where you do something that must happen whether
you threw an exception or not. An example of this is closing a file stream.
i. Methods can throw more than one exception, and they can catch more
than one type of exception, and exceptions are polymorphic:
try{
//risky code involving reptiles
}catch{SnakeBiteException){
//code for antidote
}catch(ReptileException){
//code for bandaid
}
Now if SnakeBiteException is a child class of ReptileException, we must try to
catch it first some compilers/IDEs check this for you. Otherwise, catching a
ReptileException first means the specific SnakeBiteException catch is
unreachable.AND WELL NEVER GET THE ANTIDOTE! AHHHHH!!!!!
j. If you want to call a method that throws an exception, but you dont want
to handle it in the calling method, you duck the exception:
Heres my method that throws an exception:
void riskyMethod throws SajException(){
if(noSaj){
//notice that I can pass a string parameter!
throw new SajException(Its not a party without Saj!);
}//if
}//risky method
Heres my method that uses riskyMethod without a try catch:
public void haveParty() throws SajException{
//notice lack of try catch
riskyMethod();
}
YOU MUST EITHER HANDLE AN EXCEPTION, OR DUCK IT

k. Rules for Exceptions:


1. You cannot have a catch or finally without a try
void go(){ //WHEREs the try?????
Foo f = new Foo();
catch(FoorException ex_{}
}
2. You cannot put code between the try and catch
public void newParty(){
//notice try catch
try{
riskymethod();
}
boolean haveFood = true; //THIS IS BAD!
catch(SajException saj){
inviteSaj();
}
}
3. A try must be followed by a catch or finally
public void newParty(){
//notice try catch
try{
riskymethod();
}//NEED FINALLY OR CATCH!
}
4. A try with a finally (no catch) must still declare the exception
public void newParty() throws SajException{
//notice try catch
try{
riskymethod();
}finally{
cancelPartyIfSajNotComing();
}
}

Das könnte Ihnen auch gefallen