Object-Oriented Programming with Java Lecture Notes

19 February 2009 • Polymorphism

---

Outline

Polymorphism Abstract classes. Object-Based polymorphism. Weak generics. Object subclass responsibilities.

Protocol Classes

• Classes defining protocols may have unusual properties.

• Most unusual: methods without implementations.

  • They’re declared for their signature and for documentation.

  class Dictionary
    void add(Key k, Value v) { }
    Value find(Key k) { }
    void delete(Key k) { }
  

Abstract Methods

• Needlessly implementing protocol-class methods can be a pain.

  • It’s not hard, but it may be confusing.

    class Dictionary
      void add(Key k, Value v) { }
    

  • Protocol-class methods can also be implemented.

• Abstract methods eliminate this unbearable tedium.

  • An abstract method has no implementation.

Abstract-Method Example

• Abstract methods are tagged with the abstract keyword.

  abstract void add(Key k, Value v);
  abstract void delete(Key k);
  abstract Value find(Key k);
  

Another Protocol-Class Property

• Should protocol classes with abstract methods be instantiated?

  • What happens when calling an abstract method?

    Dictionary d = new Dictionary();
    d.find("hello") // ???
    

• Variables of protocol-class type do make sense.

  • Thanks to is-a type compatibility.

    Dictionary d = new HashTableDictionary();
    

Abstract Class

• An abstract class defines abstract methods.

• An abstract class cannot be instantiated (a compile-time error).

• An abstract class is tagged with abstract.

  • Even though it has abstract methods.

    abstract class Dictionary
      abstract void add(Key k, Value v);
      // and so on.
    

Abstract-Class Methods

• An abstract class may define implemented methods.

  • The usual way of sharing code with children.

  • This can be dangerous design, easily abused.

• An abstract class with no abstract methods still can’t be instantiated.

Abstract Classes and Inheritance

• A child of an abstract class inherits as normal.

  • Both the abstract and defined methods.

  • The abstract method tag is inherited.

• A child becomes an abstract class if it fails to override a parent’s abstract method.

  • The child must be declared an abstract class.

• The child may add both defined and abstract methods.

Abstract-Class Types

• Prefer abstract classes as types over non-abstract ancestor classes.

• Abstract-class types preserve flexibility and control complexity.

  • Implementation changing flexibility.

  • Focusing on essential details defined by the protocol.

• The trade-off is loss of control over the implementation details.

Abstract Type Example

Dictionary d = new HashTableDictionary();

• Changing implementation is easy.

  HashTableDictionary d = 
    new HashTableDictionary();
  

• Changing implementation is much harder.

  • Variable and parameter types have to be rewritten.

  • Calling HashTableDictionary-specific methods is even worse.

The Object Class

• The Object class is the only class without a parent.

• Every class has Object as an ancestor.

  • Either explicitly or implicitly.

    class Blob extends Object { ... }
    class Spot { ... }
    class Drop extends Spot { ... }

  

Object Polymorphism

• Because every class is-an Object, Object provides a simple form of polymorphism.

  class Stack 
    void push(Object o) { ... }
    Object pop() { ... }
  

  • This is a stack that can hold any class instance.

    • And primitives via autoboxing.

• What is the implicit protocol in this polymorphism?

Casting

• Object polymorphism requires up- and downcasting.

  

• Incessent downcasting makes Object polymorphism tedious and dangerous.

  • The compiler handles the upcasting.

Object-Casting Problems

• Indiscriminate object casting is confusing and dangerous.

  stack.push("blah"); use(stack);
  stack.push(new Blob()); use(stack);
  stack.push(stack); use(stack);
  

• What does use() look like?

  void use(Stack s)
    ??? e = (???) s.pop();
    // and so on.
  

Generics

• Java 5 replaces Object polymorphism with generics.

  • Actually, it automates the downcasting in Object polymorphism.

  • Confusion and failures in generics are a consequence of this.

• Java versions prior to 5 had only Object polymorphism.

  • Object polymorphism also exists in various corners of post-1.4 Java.

Object Methods

• Object implements several important methods:

  public boolean equals(Object o)
  public int hashCode()
  public String toString()
  protected Object clone()
  

• Class designers should think about overriding these methods.

  • And others, depending on the child class.

  • Visit the Object JavaDoc page and see!

Equality

• When are two class instances equal?

• There are at least two interpretatons: two instances are equal if they

  • are the same instance (identity), or

  • represent similar values (similarity).

• Identity involves form and is syntatic; similarity involves content and is semantic.

• Identity implies similarity, but not vice versa.

Identity vs. Simularity

• Equality as identity:

  

• Equality as similarity:

  

• The class designer has a choice between equality as similarity or equality as identity.

Object.equals()

• Object.equals() implements identity:

  public boolean
  equals(Object o)
    return this == o 

• Identity is fast, but is usually too strict for equality.

  StringBuffer 
    sb1 = new StringBuffer("woof"),
    sb2 = new StringBuffer("woof");
  if (sb1.equals(sb2))
    // Identically false, 
    // but usually should be true.

Equality Contract

• Every equals() implementation should satisfy the equality contract.

  • Other general methods have contracts too.

• Failure to satisfy the equality contract can lead to failures, some obscure.

• Inspecting a system’s equals() implementations is quick way to estimate development quality.

Contract Rules

• Every implementation of equals() should be

  • Symmetric: x.equals(x) is always true.

  • Reflexive: if x.equals(y) then y.equals(x).

  • Transitive: If x.equals(y) and y.equals(z), then x.equals(z).

  • Null-rejecting: x.equals(null) is always false.

  • Consistent: If x and y don’t change, then x.equals(y) doesn’t either.

Equality Example

public boolean
equals(Object o)
  if this == o     // reflexive
    return true

  if o == null     // null rejecting
    return false;

  if getClass() != o.getClass()
    return false

  final Card c = (Card) o
  
  return 
    c.suit == suit && 
    c.rank == rank

Equality vs. Inheritance

• Establishing equality among indirectly related class instances can be tricky.

• The test

  if getClass() != o.getClass()
    return false
  

  can be too strong and may need to be weakened to

  if !(o instanceof class)
    return false
  

Equality Example.

• Consider 2D points.

  class Point
    int x, y
  

• What should Point.equals() mean?

  • Identity: maybe, if the points are interned.

  • Similarity: maybe, if “close enough” points are equal, or points aren't interned.

Equality Example..

• Consider colored 2D points.

  class ColoredPoint
  extends Point
    Color color
  

• What should ColoredPoint.equals() mean?

  • Does it mean the same thing as Point.equals()?

  • That is, do colors matter?

Equality Example...

• Suppose colors don't matter.

  class coloredPoint
  
    // Standard method lookup
    // equals() could be dropped.
  
    public boolean 
    equals(Object o)
      return super.equals(o)
  

• If points are interned, colored points have to be interned too.

Equality Example....

• Suppose colors matter.

  class coloredPoint
  
    public boolean 
    equals(Object o)
      return super.equals(o) && 
        color.equals(
          ((coloredPoint) o).color)
  

• If colored points are interned, do colors have to be interned too?

Equality Example.....

• If colors matter, then points and colored points are incomparable.

• Both cp1.equals(p1) and p1.equals(cp1) fail because

  getClass() == o.getClass()
  

  fails.

• Is that reasonable? Shouldn't
  coloredPoint(1, 2, Color.RED) equal
  point(1, 2)?

Equality Example......

• Colors matter, but points and colored points are comparable.

• Both cp1.equals(p1) and p1.equals(cp1) fail because

  getClass() == o.getClass()
  

  fails.

• Is that reasonable? Shouldn't
  coloredPoint(1, 2, Color.RED) equal
  point(1, 2)?

Object.hashCode()

• o.hashCode() returns an int hash code for o.

• The hashCode() contract:

  • If x.equals(y), then
    x.hashCode() == y.hashCode().

• Overriding equals() requires overriding hashCode().

  • And the override must satisfy the hashCode() contract.

hashCode() Example

• Object.hashCode() returns a hash code based on instance address.

• Object.hashCode() doesn’t obey the hashCode() property with respect to Card.equals(). (Why?)

  class Card
  
    private int rank;  // 1 to 13
    private char suit; // c, d, h, or s
  
    int hashCode()
      return rank + suit;
    

Object.toString()

• The instance method String toString() returns a printable representation of this.

• Override toString() for significant classes.

  employeeName.toString() →
  "EmployeeName@1cd2e5f", not so good.
  

  employeeName.toString() →
  "George Leroy Tirebiter", better.

Summary

• Polymorphism is your exploitable friend.

  • Unfortunately implemented with the chain-saw of inheritance.

• Abstract classes are one way of defining protocol classes.

• The Object class provides a week form of polymorphism.

  • And several subclass responsibilities.

Credits

• Plato by Yuxuan.fishy.Wang, under an AT NC ND Creative-Commons license.