Java Midterm Review Sheet
(Shamelessly ripped from Head First Java, Dave’s Slides, and some kid who I mugged for his Java notes…sorry 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.
Here’s 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 doesn’t 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 don’t 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 object’s 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 IT’S 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 can’t 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 can’t change only the return type g.
Overriding
3.
You can vary access level in any direction. i.
if you want to change the behavior of a method, but don’t 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 can’t be less accessible. h.
THE ULTIMATE SUPERCLASS: OBJECT (DUN DUN DUN!) i.
Any class that doesn’t 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 don’t 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 Cruise’s costar?) a.
Used to handle risky code – code you CAN’T 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.
Catch is where you try to recover from something bad that happened. e.
A method throws exceptions when something fails at runtime. f.
An exception is an Object! g.
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 WE’LL NEVER GET THE ANTIDOTE! AHHHHH!!!!! j.
If you want to call a method that throws an exception, but you don’t want to handle it in the calling method, you duck the exception:
Here’s my method that throws an exception: void riskyMethod throws SajException(){
if(noSaj){
//notice that I can pass a string parameter!
throw new SajException(“It’s not a party without Saj!”);
}//if
}//risky method
Here’s 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(){
//WHERE’s 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();
}
}