Polymorphism through Interfaces

Polymorphism through Interfaces
With Examples in Java

Computer Science Department

bernstdh@jmu.edu

A Review of Interfaces

Basics:
- An interface provides a view of a set of services provided by a class
- A class that realizes an interface promises that it will implement all of the methods in the interface
Uses:
- Describing similarities between classes that are not related hierarchically
- Revealing the capabilities of an object without revealing its class (sometimes called anonymous objects)

Polymorphism Revisited

Etymology:
- From the Greek - "having many forms"
Some Uses of the Term:
- Coercion of one type to another can be thought of as polymorphism
- Method overloading can be thought of as polymorphism
- Specialization results in polymorphism (i.e., subclass polymorphism)
Our Concern Here:
- Polymorphism that results from implementing an interface
- At run-time, an object may take the form of any interface it implements

Interfaces and Polymorphism

Compile Time:
- An object in a class that implements an interface essentially "is a" member of that interface (e.g., a Person "is a" Ordered)
Run Time:
- An object can respond to messages that correspond to methods it implements or inherits (in other words, the interface doesn't change anything)

Interfaces and Polymorphism (cont.)

Suppose we have the following interfaces and classes:
- public interface Ordered {...}
- public interface Animated {...}
- public class Versatile implements Ordered, Animated {...}
Will The Following Compile?
- Animated a = new Animated();
- Animated a = new Versatile();
- Ordered o = new Animated();
- Ordered o = new Ordered();
- Ordered o = new Versatile();

Interfaces and Polymorphism (cont.)

Suppose we have the following interfaces, classes and declarations:
- public interface Ordered { public abstract int compareTo(Ordered other); }
  
  public class Versatile implements Ordered { // Details omitted }
  
  Ordered o, p; Versatile v, w;
Will The Following Compile?
- o.compareTo(p);
- v.compareTo(w);
- o.compareTo(v);

Overloading and Objects as Parameters

Suppose we have the following interfaces and classes:
- public interface Ordered {...}
- public interface Animated {...}
- public class Versatile implements Ordered, Animated {...}
And the following methods in another class:
- public void add(Animated item) {...}
- public void add(Ordered item) {...}
- public void add(Versatile item) {...}
What happens at compile-time and at run-time when:
- add() is passed a Versatile that is declared to be a Versatile?
  
  Compile-Time: The statement compiles
  
  Run-Time: add(Versatile item) is executed
- add() is passed a Versatile that is declared to be an Animated?
  
  Compile-Time: The statement compiles
  
  Run-Time: add(Animated item) is executed
- add() is passed a Versatile that is declared to be a Ordered?
  
  Compile-Time: The statement compiles
  
  Run-Time: add(Ordered item) is executed

Overloading and Objects as Parameters (cont.)

Suppose we have the following methods in another class (note the difference from the previous example):
- public void add(Animated item) {...}
- public void add(Ordered item) {...}
What happens when at compile-time and at run-time when:
- add() is passed a Versatile that is declared to be a Versatile?
  
  Compile-Time: The reference to add() is determined to be ambiguous (hence the statement won't compile)
  
  Run-Time: N/A
- add() is passed a Versatile that is declared to be an Animated?
  
  Compile-Time: As before, the statement compiles
  
  Run-Time: As before, add(Animated item) is executed
- add() is passed a Versatile that is declared to be a Ordered?
  
  Compile-Time: As before, the statement compiles
  
  Run-Time: As before, add(Ordered item) is executed

There's Always More to Learn