CISC 3115 — Lecture 7 — Class Inheritance

CISC 3115
Modern Programming Techniques
Lecture 7
Class Inheritance

Sample Classes — `UnboundedCounter` & `UpperBoundedCounter`

UnboundedCounter: 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 UnboundedCounter, 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 UnboundedCounter");

		UnboundedCounter uc = new UnboundedCounter();
		System.out.println("Initially: " + uc);

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

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

		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 UnboundedCounter
Initially: A unboundedCounter with value 0
After 20 up's: A unboundedCounter with value 20
After 3 down's: A unboundedCounter 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

Implementation 1 — Unrelated Types

UnboundedCounter.java

UpperBoundedCounter.java

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

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

	int getVal() {return val;}

	public String toString() {
		return "A unboundedCounter 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 UnboundedCounter class
  - Given the absence of ANY constructor, a default constructor is (implicitly) available, so one would be able to write new UnboundedCounter()
- The UpperBoundedCounter would still require a constructor be written (since a limit must be supplied).

Implementation 2 — Composition

UnboundedCounter.java

UpperBoundedCounter.java

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

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

	int getVal() {return val;}

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

	private int val;
}

public class UpperBoundedCounter {
	UpperBoundedCounter(int limit) {
		unboundedCounter = new UnboundedCounter();
		this.limit = limit; 
	}	

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

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

	
	private UnboundedCounter unboundedCounter;	
	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 B acquires all instance variables and methods of C.
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
- By identical, we mean the signature of B's method is odentical to that of C
- This facility leads to one of the most powerful and useful aspects of OOP.
- There's the analogous 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.
- We see examples of this in the next code presentations
We speak of C as the parent or superclass and B as the child or subclass.

The immediate question becomes how B accesses the state/behavior it inherits from C.

Method 1. Removing the `private` of the parent's instance variable (`val`)

UnboundedCounter.java

UpperBoundedCounter.java

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

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

	int getVal() {return val;}

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

	/*private*/ int val;
}

public class UpperBoundedCounter extends UnboundedCounter {
	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;
}

First thing to note is B does not declare val nor redefine down or getVal as they are the same logic as in class C
- It's actually more than that; by not redefining this state and behavior in the subclass, the programmer is specifying that they are inherited from the superclass (think upcasting and you might start to get the picture).
Removes all access control from the superclass state

Method 2. Using `protected`

UnboundedCounter.java

UpperBoundedCounter.java

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

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

	int getVal() {return val;}

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

	protected int val;
}

public class UpperBoundedCounter extends UnboundedCounter {
	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;
}

Protected provides access control to subclasses
Requires going back and modifying superclass (unless was designed that way to begin with)
Access to 'hidden' superclass method is provided via super keyword acting as qualifier.
the above code uses direct access to superclass' state as well as calling superclass methods

Method 3. Using the parent's methods

UnboundedCounter.java UpperBoundedCounter.java

public class UnboundedCounter { UnboundedCounter() {val = 0;} void up() {val++;} void down() {val--;} int getVal() {return val;} public String toString() { return "A unboundedCounter with value " + val; } private int val = 0; }

public class UpperBoundedCounter extends UnboundedCounter { 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; }

getVal provides access to the value and again, we use super to access the superclass' up method
Requires going back and modifying superclass (unless was designed that way to begin with)
Access to 'hidden' superclass method is provided via super keyword acting as qualifier.
the above code uses direct access to superclass' state as well as calling superclass methods

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)
- UnboundedCounter
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
```
UnboundedCounter
	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 UnboundedCounter, an UpperBoundedCounter object can appear wherever a UnboundedCounter 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 UnboundedCounter, it inherited ALL UnboundedCounter's state and behavior, and thus, any method or field access that can be performed on a UnboundedCounter object can be performed on an UpperBoundedCounter object as well.
  - The inverse is not true: UpperBoundedCounter may contain state/behavior tht UnboundedCounter does not (e.g. limit and getLimit), thus a UnboundedCounter object cannot appear in a context expecting an UpperBoundedCounter.

This means that the following is perfectly legal:

UnboundedCounter uc;
UpperBoundedCounter ubc = new UpperBoundedCounter(10);
uc = ubc;

or equivalently (but possibly more confusing):

UnboundedCounter uc = new UpperBoundedCounter(10);

but not

UpperBoundedCounter ubc = new UnboundedCounter(); // 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) { UnboundedCounter [] counters = {new UnboundedCounter(), new UpperBoundedCounter(10)}; for (int i = 0; i < counters.length; i++) { System.out.println("Playing with counters[" + i + "]:"); doIt(counters[i]); } } static void doIt(UnboundedCounter unboundedCounter) { System.out.println("\tInitially: " + unboundedCounter); for (int i = 1; i <= 20; i++) unboundedCounter.up(); System.out.println("\tAfter 20 up's: " + unboundedCounter); for (int i = 1; i <= 3; i++) unboundedCounter.down(); System.out.println("\tAfter 3 down's: " + unboundedCounter); } }

Playing with counters[0]: Initially: A unboundedCounter with value 0 After 20 up's: A unboundedCounter with value 20 After 3 down's: A unboundedCounter 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

Given the following declarations:

UnboundedCounter uc;
UpperBoundedCounter ubc;

it is clear that the type of the variable uc is the class UnboundedCounter (and similarly for the type of 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.

If we now add code to create objects to be referenced by the variables:

UnboundedCounter uc = new UnboundedCounter();
UpperBoundedCounter ubc = new UpperBoundedCounter(12);

while we can tell the types of the objects reference by uc (it's a UnboundedCounter object) and y ubc (an UpperBoundedCounter object), it's important to realize that the objects are not actually created until we execute the program (and actually call the new operator).

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

As a result of the above, at runtime, there are two types associated with a reference variable:

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

The 'rule of polymorphism' states that when we call an instance method of a class on a receiver, we look for the method in the class of the object rather than the class of the variable, i.e., we use the dynamic type rather than the static type to determine which class' methods we use.

Again, polymorphism means 'many faces'; each object responds to the message in its own appropriate manner based on its own type) … the type of the reference variable is irrelevant.

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 UnboundedCounter and UpperBoundedCounter objects manifested completely different behavior
- Similarly 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/static 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: searching 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 polymorphic

A Consequence of the Above Consequence

Since subclass objects can appear anywhere superclass object can appear, code that manipulates UnboundedCounter objects can operate — without any further modification — on any object belonging to a subclass of UnboundedCounter
- Thus, defining and introducing a UpperBoundedCounter into a project does not require any recompilation or other deployment of any existing code that works with UnboundedCounter.
  - 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(UnboundedCounter unboundedCounter) {
	while (unboundedCounter.getVal() > 0)
		unboundedCounter.down();
					
```
- Furthermore, 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(UnboundedCounter unboundedCounter, int howMany) {
	for (int i = 1; i <= howMany; i++)
		unboundedCounter.up();	
}
						
```
    will invoke the proper up method depending upon whether a UnboundedCounter or UpperBoundedCounter object is passed to jumpUp (ensuring the integrity of the limit for the latter).

Up- and Down-Casting

Note that all of the above is similar to what we did with interface implementation and inheritance in the previous lecture; the only difference here is the 'root' of the hierarchy (UnboundedCounter in our example) is a class rather than an interface.

In fact, one could (and often does) have a hierarchy where the root is an interface and below it are subinterfaces and/or implementing classes. Below the subinterfaces there might be further subinterfaces, and/or implementing classes, and below implementing classes can be furthe subclasses.
- The general rules:
  - Interfaces extend interfaces (inheritance)
  - Classes implement interfaces (implementation) and extend classes (inheritance)

The is-arelationship between subclass and superclass, and the consequential Substitution Principle, tells us that an object of a subclass can always appear in any context that an object of the superclass can appear in.

As a result, it is always legal to assign an object of the sublass to a variable of the superclass:
```
UnboundedCounter uc = new UpperBoundedCounter(12);
		
```
```
UnboundedCounter uc;
UpperBoundedCouner ubc;
…
uc = 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. UnboundedCounter) 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);
UnboundedCounter uc = ubc;	// perfectly legal — upcast
ubc = uc;		// shouldn't this be legal? — uc contains a reference to an UpperBoundedCounter object

On the other hand, what about this?

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

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

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

UpperBoundedCounter ubc = uc;	// 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)uc;	// 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)

A Summary of Interfaces vs Classes wrt Casting

Remember upcasting is always legal and does not require an explicit cast; downcasting requires an explicit cast and may fail with a ClassCastException

Interfaces:
- upcast to their superinterfaces (direct or otherwise)
- downcast to their subinterfaces (direct or otherwise)
- downcast to their implementing classes (direct or otherwise)
Classes:
- upcast to the interfaces they implement (direct or otherwise)
- upcast to their superclasses (direct or otherwise)
- downcast to their subclasses (direct or not)

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

Consider the following class:

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 Name {

	…

	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

The issue is resolved through yet another use of super:

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

in the context of constructors, super is used by a subclass to pass constructor arguments to the superclass

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?

The situation is different if FormalName had been defined using composition instead of inheritance:

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

Abstract Classes

Revisiting our Collection interface:

interface Collection {
	boolean add(int value);
	boolean remove(int value);
	int size();
	boolean isEmpty();
}

As we've discussed numerous times, isEmpty can leverage off size:

boolean isEmpty() {return size() == 0;}

i.e., we really don't need for every implementing class to write its own copy of isEmpty. However, interfaces do not permit method bodies, and we WANT our Shape interface to include an isEmpty method. We can get what we want with an abstract class

abstract class AbstractCollection implements Collection {
	//public abstract boolean add(int value);		// unnecessary
	/public abstract boolean remove(int value);
	//public abstract int size();
	public boolean isEmpty() {return size() == 0;}
}

An abstract class is somewhere between an interface and a fully specified class: some of its methods remain undefined (i.e., no bodys).
Abstract classes must be declared abstract in the class header
If an abstract class is implementing an interface, not defining one or more of the interfaces methods makes the class abstract.
- One can simply omit the header for the undefined class
  - E.g. in AbstractCollection above, one need not include the method header for size
- Or one can include the abstract keyword (and public) in the method header if this is an interface method.
If the abstract class is NOT implementing an interface, and wishes to contain an abstract method, i.e.., one that must be defined by some subclass, it again uses the abstract keyword in the method header.
Subsequent subclasses of AbstractCollection thus no longer need to define isEmpty.
AbstractCollection (i.e., a class that only imeplements some of the methods of the interface it is 'implementing') is sometimes referred to as a skeletal or partial implementation

Finally, … Something to Think About

What sort of hierarchy could we construct if we wanted: UpCounter, DownCounter, UnboundedCounter, UppperBoundedUpCounter, UppperBoundedCounter, LowerBoundedDownCounter, LowerBoundedCounter, BoundedCounter?

What issues/problems arise?

Summary

Interfaces represent an obligation to implement the specified methods
- (implementing) classes implement interfaces
Inheritance represents an acquiring of state/behavior from supeerclass to subclass
- (sub)Interfaces inherit other (super)interfaces
- (sub)classes inherit other (superclasses)
(sub)Interfaces inherit other (super)interfaces; (sub)classes inherit other (superclasses); (implementing) classes implement interfaces
assigning a reference from a
- sub (interface/class) to a super (interface/class) is an upcast, no cast is required, and is always legal
- super (interface/class) to a sub (interface/class) is a downcast, requires an explicit cast and may cause a runtime ClassCastException
- any other class/interface to another is illegal and causes a compilation error
Java does not permit multiple inheritance, but does permit multiple implementation of interfaces
- In fact, that is one of the purposes of interfaces … to permit a class to manifest multiple behaviors, i.e., to be an is-a for many behavior specifications
Abstract classes permit partial definition of class behavior
- This often produces convenience/utility/skeletal classes providing much of the behavior for any subclass which then implements some basic core methods
  - We will see examples of this in the JCF
Overloading is when two methods (in the same scope) share the same name but different signatures (parameters lists)
- Overloading is handled a compilation time
Overriding is when a method has the exact same signature as an inherited method
- Overriding is resolved at runtime by the Rule of Polymorphism and is one of the core tools of OOP
  - The type of a reference variable is static, i.e., known at compile-time
  - The type of an object is only known onces the object us created at runtime
  - Remember, the method called is the one belonging to the dynamic type object, not the compile-time type of the reference variable

CISC 3115 Modern Programming Techniques Lecture 7 Class Inheritance

Sample Classes — UnboundedCounter & UpperBoundedCounter

A Sample Application Program

Implementation 1 — Unrelated Types

Implementation 2 — Composition

Implementation 3 — Inheritance

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

Method 2. Using protected

Method 3. Using the parent's methods

More Terminology

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

Polymorphism

What's going on here?

Static vs Dynamic Types

The Rule of Polymorphism

Saying it Another Way

A Consequence of the Above Consequence

Up- and Down-Casting

A Summary of Interfaces vs Classes wrt Casting

Runtime vs Compile-time Polymorphism

Initializing the Superclass

What if We Had Used Composition?

Abstract Classes

Finally, … Something to Think About

Summary

Code Relevant to This Lecture

CISC 3115
Modern Programming Techniques
Lecture 7
Class Inheritance

Sample Classes — `UnboundedCounter` & `UpperBoundedCounter`

Method 1. Removing the `private` of the parent's instance variable (`val`)

Method 2. Using `protected`