Sample Classes — Counter & UpperBoundedCounter

• Counter: current value (val), increment (up), decrement (down), retrieve current value (getVal), toString
• UpperBoundedCounter: current value (val), upper bound (limit), bounded increment (up), decrement (down), retrieve current value (getVal), retrieve limit (getLimit), toString

• Note: Where there's an UpperBoundedCounter, there could also be a LowerBoundedCounter, and where there's UpperBoundedCounter and LowerBoundedCounter there could also be …. (By the same token, where there's a Counter, there could be an UpCounter and/or a DownCounter.)

A Sample Application Program

• Applicable to all of the implementations presented below

public class App {
	public static void main(String [] args) {
		System.out.println("Playing with Counter");

		Counter c = new Counter();
		System.out.println("Initially: " + c);

		for (int i = 1; i <= 20; i++)
			c.up();
		System.out.println("After 20 up's: " + c);

		for (int i = 1; i <= 3; i++)
			c.down();
		System.out.println("After 3 down's: " + c);

		System.out.println();	//---------

		System.out.println("Playing with UpperBoundedCounter");

		UpperBoundedCounter ubc = new UpperBoundedCounter(10);
		System.out.println("Initially: " + ubc);

		for (int i = 1; i <= 20; i++)
			ubc.up();
		System.out.println("After 20 up's: " + ubc);

		for (int i = 1; i <= 3; i++) 
			ubc.down();
		System.out.println("After 3 down's: " + ubc);
	}
}
			

Playing with Counter
Initially: A counter with value 0
After 20 up's: A counter with value 20
After 3 down's: A counter with value 17

Playing with UpperBoundedCounter
Initially: A upper-bounded counter with value 0 and limit 10
After 20 up's: A upper-bounded counter with value 10 and limit 10
After 3 down's: A upper-bounded counter with value 7 and limit 10
			

Some Terminology

• behavior — methods
• state — instance variables
• receiver — object whose method is being called
  • c.up()
  • sentence.indexOf(" ")

Implementation 1 — Unrelated Types

public class Counter {
	Counter() {val = 0;}

	void up() {val++;}	
	void down() {val--;}	

	int getVal() {return val;}

	public String toString() {
		return "A counter with value " + val;
	}

	private int val;
}
			

public class UpperBoundedCounter {
	UpperBoundedCounter(int limit) {
		val = 0;
		this.limit = limit;
	} 

	void up() {if (val < limit) val++;}	
	void down() {val--;}	

	int getVal() {return val;}
	int getLimit() {return limit;}

	public String toString() {
		return "A upper-bounded counter with value " + val + 
				" and limit " + limit;
	}

	private int val;
	private int limit;
}
			

• No shared behavior or state
• Any shared semantics is purely 'concindental' and enforced solely by discplined programming rather than the language
  • In particular, they are not the same type, cannot reside in the same array of other data structure, or be passed to the same method
• Code (and data) redundancy
• As an aside: the initialization of val in both classes could have been done at the point of declaration:

  private int val = 0;
  		

  • This would eliminate the need to explicitly code a default constructor for the Counter class
    • Given the absence of ANY constructor, a default constructor is (implicitly) available, so one would be able to write new Counter()
  • The UpperBoundedCounter would still require a constructor be written (since a limit must be supplied).

Implementation 2 — Composition

public class Counter {
	Counter() {val = 0;}

	void up() {val++;}	
	void down() {val--;}	

	int getVal() {return val;}

	public String toString() {
		return "A counter with value " + val;
	}

	private int val;
}
			

public class UpperBoundedCounter {
	UpperBoundedCounter(int limit) {
		counter = new Counter();
		this.limit = limit; 
	}	

	// New methods
	void up() {if (counter.getVal() < limit) counter.up();}	
	int getLimit() {return limit;}
	public String toString() {
		return "A upper-bounded counter with value " + getVal() + 
				" and limit " + limit;
	}

	//Delegation methods
	void down() {counter.down();}
	int getVal() {return counter.getVal();}

	
	private Counter counter;	
	private int limit;
}
			

• composite/containing object vs simple/member/contained object
• Leverages/shares existing behavior/state
• Requires delegation methods
• Any leveraging of methods is the responsibility of the programmer (who has to code the appropriate delegation method).
  • I.e., the fact that the names/signatures of the methods are the same between the two classes is totally irrelevant at the language level
• Again, they are not the same type, and thus cannot reside in the same array or other data structure, or be passed to the same method
• In summary, there is no recognition at the language level that the composite and member types bear any relationship to each other.
• Represents a has-a relationship
• Allows factoring out of common behavior/state (for the purpose of sharing) into the member object
• The sharing in our example is between the composite and the member
  • This is one of the signs that inheritance (see below) may be lurking about
  • Contrast this with an Address class being used as a member by a Person class and a Company class
    • Here the desired sharing occurs between the two composite types (Person and Company).
• Composition is the basic construction technique employed in languages lacking inheritance

Implementation 3 — Inheritance

• If a class B includes extends C in its class header:

  class B extends C {
  	…
  }
  		

  class B is said to inherit from class C
  • This means that all instance variables an methods of C belong to B as well.
• Of course, B can define its own instance variables and methods as well
• The interesting part is when B defines methods identical to those of C
  • This facility leads to one of the most powerful and useful aspects of OOP.
  • There's also the situation where B defines instance variables with the same name as one in C. While this variable shadowing is legal, it is not all that useful, and in fact, is not recommended.

Removing the private of the parent's instance variable (val)

public class Counter {
	Counter() {val = 0;}

	void up() {val++;}	
	void down() {val--;}	

	int getVal() {return val;}

	public String toString() {
		return "A counter with value " + val;
	}

	/*private*/ int val;
}
			

public class UpperBoundedCounter extends Counter {
	UpperBoundedCounter(int limit) {this.limit = limit;} 

	// Overridden methods
	void up() {if (val < limit) val++;}
	public String toString() {
		return "A upper-bounded counter with value " + val + 
				" and limit " + limit;
	}

	// new method
	int getLimit() {return limit;}

	private int limit;
}
			

Using protected

public class Counter {
	Counter() {val = 0;}

	void up() {val++;}	
	void down() {val--;}	

	int getVal() {return val;}

	public String toString() {
		return "A counter with value " + val;
	}

	protected int val;
}
	
			

public class UpperBoundedCounter extends Counter {
	UpperBoundedCounter(int limit) {this.limit = limit;} 

	// Overridden methods
	void up() {if (getVal() < limit) super.up();}	
	public String toString() {i
		return "A upper-bounded counter with value " + val + 
				" and limit " + limit;
	}

	int getLimit() {return limit;}

	private int limit;
}
			

Using the parent's methods (super)

Counter.java	UpperBoundedCounter.java
public class Counter { Counter() {val = 0;} void up() {val++;} void down() {val--;} int getVal() {return val;} public String toString() { return "A counter with value " + val; } private int val = 0; }	public class UpperBoundedCounter extends Counter { UpperBoundedCounter(int limit) {this.limit = limit;} // Overridden methods void up() {if (getVal() < limit) super.up();} public String toString() { return "A upper-bounded counter with value " + getVal() + " and limit " + limit; } int getLimit() {return limit;} private int limit; }

• Inherited behavior/state
• Represents an is-a relationship
  • Since methods (and state) are inherited, everyhting you could do with objects of the original class can be done with objects of the new class
• No delegation method needed, the behavior (and state) is immediately available
• The sharing is implicit, i.e., other than the extends clause, there's no sign of the inherited class (superclass) in the definition of the inheriting class (subclass).

More Terminology

• superclass — class being inherited from (i.e., being extended)
  • Counter
• subclass — the inheriting class (i.e., the class doing the extending)
  • UpperBoundedCounter
• overriding — defining a method in the subclass that has the same signature as a method in the superclass
• class hierarchy — a tree consisting of classes with and in which each parent is the superclass of its children

  Counter
  	UpperBoundedCounter
  		

  • The superclass relationship is transitive, leading to ancestor superclasses
  • Similarly, the subclass relationship is transitive, leading to descendant superclasses

The Substitution Principle — A Consequence of the is-a Nature of Inheritance

• Since an UpperBoundedCounter is-a Counter, an UpperBoundedCounter object can appear wherever a Counter object can appear
  • This is known as the Substitution Principle: an object of a subclass may always appear in a context expecting an object of the superclass
  • From a practical point of view, this makes sense — since UpperBoundedCounter is a subclass of Counter, it inherited ALL Counter's state and behavior, and thus, any method or field access that can be performed on a Counter object can be performed on an UpperBoundedCounter object as well.
    • The inverse is not true: UpperBoundedCounter may contain state/behavior tht Counter does not (e.g. limit and getLimit), thus a Counter object cannot appear in a context expecting an UpperBoundedCounter.
• This means that the following is perfectly legal:

  Counter c;
  UpperBoundedCounter ubc = new UpperBoundedCounter(10);
  c = ubc;
  		

  or equivalently (but possibly more confusing):

  Counter c= new UpperBoundedCounter(10);
  		

  but not

  UpperBoundedCounter ubc = new Counter(); // illegal
  		

Polymorphism

• And now we write the application that is — to some extent — the whole point of this presentation:

App2.java

App2.out

public class App2 { public static void main(String [] args) { Counter [] counters = {new Counter(), new UpperBoundedCounter(10)}; for (int i = 0; i < counters.length; i++) { System.out.println("Playing with counters[" + i + "]:"); doIt(counters[i]); } } static void doIt(Counter counter) { System.out.println("\tInitially: " + counter); for (int i = 1; i <= 20; i++) counter.up(); System.out.println("\tAfter 20 up's: " + counter); for (int i = 1; i <= 3; i++) counter.down(); System.out.println("\tAfter 3 down's: " + counter); } }

Playing with counters[0]: Initially: A counter with value 0 After 20 up's: A counter with value 20 After 3 down's: A counter with value 17 Playing with counters[1]: Initially: An upper-bounded counter with value 0 and limit 10 After 20 up's: An upper-bounded counter with value 10 and limit 10 After 3 down's: An upper-bounded counter with value 7 and limit 10

What's going on here?

Static vs Dynamic Types

Counter c;
UpperBoundedCounter ubc;

• We don't have to execute the program see this; similarly; we therefore say that the type of the reference variable is its static type.
  • Furthermore, the compiler — when parsing/reading the source file — also has access to this information, and we therefore also speak of the compile-time type of a reference variable.

Counter c = new Counter();
UpperBoundedCounter ubc = new UpperBoundedCounter(12);

• Thus, since the object does not actually come into existence until runtime, we speak of the type of the object as a dynamic or runtime type.

The Rule of Polymorphism

• the static type of the variable
• the dynamic type of the object referenced by the variable

Saying it Another Way

• Definition of polymorphism:
  • many faces
  • single interface for many types
• Same operator/method causes the execution of different actions (methods) depending of the operand(s) — usually the receiver
  • Asking for help in a hospital vs a police station vs a grocery vs Home Depot
  • Calling up on Counter and UpperBoundedCounter objects manifested completely different behavior
  • Similary for calling toString
• When an overriden method is encountered
  • the class of the receiver object determines which method is called;
    • this class is not known until runtime (when the object is created), and is therefore known as the runtime/dynamic type of the object
    • this stands in contrast to the class/type of the variable containing the reference to the object, which is known at compile-time, and is thus called the compile-time/statc type
      • The compile-time type is always an ancestor of the object's runtime type in the class hierarchy
  • The above can be restated as: serching for the proper method begins at the runtime-type of the object, and not the compile-time type
  • this process is called method resolution and occurs at runtime!
  • the overridden method is said to be polymporphic

A Consequence of the Above Consequence

• Since subclass objects can appear anywhere superclass object can appear, code that manipulates Counter objects can operate — without any further modification — on any object belonging to a subclass of Counter
  • Thus, defining and introducing a UpperBoundedCounter into a project does not require any recompilation or other deployment of any existing code that works with Counter.
    • For example, the following method can be passed a UpperBoundedCounter despite the fact that the method was written a month ago, and UpperBoundedCounter just coded this morning:

    void clear(Counter counter) {
    	while (counter.getVal() > 0)
    		counter.down();
    					

  • Furthermore, the since the method invoked is the one belonging to the object (and not merely the reference variable acting as the receiver), the resulting behavior is that appropriate to the object.
    • Thus the method:

      void jumpUp(Counter counter, int howMany) {
      	for (int i = 1; i <= howMany; i++)
      		counter.up();	
      						

      will invoke the proper up method depending upon whether a Counter or UpperBoundedCounter object is passed to jumpUp (ensuring the integrity of the limit for the latter).

Up- and Down-Casting

• As a result, it is always legal to assign an object of the sublass to a variable of the superclass:

  Counter c = new UpperBoundedCounter(12);
  		

  Counter c;
  UpperBoundedCouner ubc;
  …
  c = ubc;
  		

  • In some sense, we are converting/casting the subclass reference to a superclass reference.
  • Since we are going up the class hierarchy, we call this an upcast
  • Thus it is always legal to perform an upcast and no special syntax is required when doing it
• In contrast, a downcast converts/casts a superclass (e.g. Counter) reference to that of a subclass (UpperBoundedCounter)
  • While that sounds like it should be an error, consider the following code:

    UpperBoundedCounter ubc = new UpperBoundedCounter(10);
    Counter c = ubc;	// perfectly legal — upcast
    ubc = c;		// shouldn't this be legal? — c contains a reference to an UpperBoundedCounter object
    				

  • On the other hand, what about this?

    Counter c = new Counter();
    UpperBoundedCounter ubc = c;		// should be illegal — c contains a reference to a Counter object
    				

  • And just to drive the point further home, what about this?

    Counter c;
    Scanner keyboard = new Scanner(System.in);
    System.out.print("c or u? ");
    String choice = keyboard.next();
    if (choice.equals("c")
    	 c = new Counter();
    else
    	c = new UpperBoundedCounter(12);	// legal upcast
    
    UpperBoundedCounter ubc = c;	// legal? illegal?
    				

  • We see that whether or not the downcast 'makes sense' depends on the (dynamic) type of the object referenced by the superclass variable.
    • And this type is not known until runtime
  • The compiler therefore requires us to indicate we 'understand' the risks by having us use the language's casting syntax:

    UpperBoundedCounter ubc = (UpperBoundedCounter)c;	// legal? illegal? ... won't know until runtime
    				

  • If the cast doesn't make sense (i.e., the referenced object is not compatible with the subclass), a ClassCastException is thrown by the runtime.
• Finally, up- and down-casts are the only legal ones; any other casting of class types is illegal and results in a compilation error (for example two sibling classes can never be cast to each other)

Runtime vs Compile-time Polymorphism

• By default, when we speak of polymorphism, we usually mean runtime polymorphism (method resolution occurs at runtime).
  • This is in contrast to overloading, where the methods have different signatures and whose resolution can be (and is) performed by the compiler
    • Overloading is therefore often categorized as compile-time polymorphism

Initializing the Superclass

class Name {
	Name(String first, String last) {
		this.first  first;
		this.last = last;
	}

	…

	private String first, last;
}

Note that one must supply first and last names when creating a Name object.

Name name = new Name("Gerald", "Weiss");

Now, consider a subclass FormalName that inherits from Name and adds a salutation:

class FormalName extends {

	…

	private String salutation;
}

FormalName is-a Name as well, and thus when one creates a FormalName you are also (implicitly) creating a Name object and thus need to supply a first/last name as well as the salutation, e.g.:

FormalName formalName = new FormalName("Mr.", "Gerald", "Weiss");

this gives us the constructor:

FormalName(String salutation, String first, String last) {
	this.salutation = salutation;
	…
}

The question becomes, how do we initialize the instance variables of the Name class? FormalName's constructor cannot/should-not do it:

• first andlast may be declared private (as they are above).
• first andlast are not the responsibility of FormalName; they belong to Name

FormalName(String salutation, String first, String last) {
	super(first, last);
	this.salutation = salutation;
}

• This is similar to the use ofthis in the constructor but that is to pass arguments between overloaded constructors within the same class.
• super must be the first line of code in the constructor
  • We want to make sure the superclass is fully and properly initialized before we begin working on initializing the subclass.

What if We Had Used Composition?

class FormalName {
	FormalName(String salutation, String first, String last) {
		name = new Name(first, last);
		this.salutation = salutation;
	}

	…

	private Name name;
	private String salutation;
}

• name is an actual reference variable under FormalName's control and must have an object created and its reference assigned to name
• Remember, any Name methods must be repeated as delegation methods in FormaName

Finally, … Something to Think About

Code Relevant to This Lecture