Interfaces: CS 310 Lecture notes

Object-Oriented Programming with Java Lecture Notes

24 February 2009 • Interfaces

Outline

Abstract classes and interfaces.
- Traits
- Types
Copying and cloning.
- Copying and instance safety.
- Deep and shallow copying.

Polymorphism

polymorphism in action!

Inheritance

inheritance in action!

Problems

Inheritance and protocol classes are overly heavy mechanisms for implementing IS-A relations.
- “Too much mechanism” means “complexity.”
Simpler inheritance would be nice, but is technically difficult.
Simpler protocol classes is a more straightforward, practical solution.
- Not straightforward enough, though.

Abstract Classes

The abstract keyword identifies features intended for protocol definition.
- Abstract methods don’t have implementations.
- Abstract classes don’t get instantiated.
But, a child can have only one parent.
- Or, can only satisfy one protocol.

Interfaces

An interface is a simpler form of abstract class.
- Abstract methods only, no defined methods.
- All methods are non-static and public.
- All variables are public, static, and final.
An interface can also contain classes and other interfaces.

Interface Examples

interface Candy {
  public abstract int calorieCount();
  Nuts [] containsNuts();
  boolean hasFlavonoids();
  }  

interface 3DRectangle {
  double height();
  double width();
  double length();
  }

Interface Specifications

Interfaces can be package-local (default) or public.

Interfaces can extend other interfaces.

interface ChocolateBar 
extends Candy { 
  ChocolateKind chocolateKind();
  // and so on.
  }

Interfaces can combine other interfaces too.

public interface ChocolateBar 
extends Candy, 3DRectangle { ... }

Interfaces and Classes

A class implements one or more interfaces.

class ThreeMusketeers
implements ChocolateBar
  int calorieCount() { ... }
  boolean hasFlavonoids { return true; }
  // and so on

A class may implement interfaces and extend a class.

A class not implementing an interface method becomes abstract.

Constant-Defining Interfaces

Constant-defining interfaces are frowned upon.

interface Universals {
  public static final int 
    tearsCried = 96,
    theAnswer = 42;
    }

Use one-off classes instead.

abstract class Universals {
  public static final int 
    tearsCried = 96,
    theAnswer = 42;
    }

Trait-Defining Interfaces

Use interfaces to define traits: small, well-defined collections of behavior.

interface Comparable
  int compareTo(Object o);

public interface Destroyable
  void destroy();
  boolean isDestroyed();

public interface Readable
  int read(CharBuffer cb);

Trait Behaviors

Mix and match traits to give desired behaviors to classes.

class Card
implements Comparable
  int compareTo(Object o) { ... }
  // and so on.

class SecurityCertificate
implements Destroyable, Readable
  void destroy() { ... }
  boolean isDestroyed() { ... }
  int read(CharBuffer cb) { ... }
  // and so on.

Trait Specifications

Use traits to specify exactly and minimally what behavior class instances should have.

boolean beats(Comparable x) { ... }
void validate(Destroyable tag) { ... }
Message read(Readable input) { ... }

The same class instance may have several roles based on traits.

SecurityCertificate ticket = 
  new SecurityCertificate()
validate(ticket)
Message m = read(ticket)

Interfaces v Abstract Classes

Which should you use?

Trait-based “multiple inheritance” favors interfaces.

class banana implements peel, soft {...}
class apple implements seeds, crisp {...}

Interfaces form non-hierarchial types.

interface soup extends stock, aromatics {...} 
interface salad extends greens, dressing {...}

Interfaces & Abstract Classes

Use an abstract class to provide a default interface implementation.

interface MouseListener
  void mouseMotion()
  void mouseButton()
  // lots more

abstract class AbstractMouseListener
implements MouseListener
  public void mouseMotion() { ... }
  public void mouseButton() { ... }
  // lots more

class TouchPadListener
extends AbstractMouseListener
  public void mouseMotion() { ... }

Class-Instance Danger

A method can arbitrarily change class-instance parameters.
A source of obscure and dangerous errors.

Class-Instance Safety

Immutable class instances are safe.
- Hard and maybe impossible to do.
Pass a copy of the instance.
Problem solved?

Class-Instance Copying

At first glance, copying seems easy, if possibly expensive.

class T

  // Or maybe T(T t)

  T copy()
    cpy = new T()
    for each v: this.instance-variable
      cpy.v = v
    return cpy

Class-Instance Graphs

Class instances are graphs.
- A node is a class instance.
- An edge is a reference in an instance variable.
This structure has important consequences.

Shallow Copies

The obvious copy() implements a shallow copy.
- Only the top-level instance is recreated.
- The instance references are copied.
So?

Why Copy?

An important reason to copy is to protect a class instance from unexpected changes.
- A source of nasty errors.
A shallow copy doesn’t protect against unexpected changes.

Deep Copies

Protection against unexpected changes requires a deep copy.

Instance-variable references are recursively copied.

T deepCopy()
  cpy = new T()
  for each v: this.instance-variable
    cpy.v = v.deepCopy()
  return cpy

Deep-Copy Example

Blob cpy = ci.deepCopy()

`Object.clone()`

The Object method
```
protected Object clone()
```
implements copying.
- It’s another one of those subclass-responsibility Object methods.
However, by default it’s inaccessible to ancestors and their clients.

No-Clone Example

$ cat t.java
class blob { }

class t {
  public static void main(String args[]) {
    blob b = new blob();
    blob cpy = (blob) b.clone();
    }
  }

$ javac -Xlint t.java
t.java:7: clone() has protected access 
          in java.lang.Object
    blob cpy = (blob) b.clone();
                       ^
1 error

$

Default Clone

Object.clone() implements a shallow copy.
If that’s acceptable, an ancestor must
- implement the Cloneable interface,
- redeclare clone() as a public method, and
- deal with the clone-unsupported exception.
The Cloneable interface is a hack, not to be emulated.

Shallow-Clone Example

$ cat t.java
class blob 
implements Cloneable
  public blob clone() 
  throws CloneNotSupportedException
    return (blob) super.clone();

class t
  public static void main(String args[])
    blob b = new blob();
    try blob cpy = b.clone();
    catch (Exception e) { }

$ javac -Xlint t.java

$

Deep-Copying Clones

If a class needs a deep-copying clone, it
- Overrides Object.clone() as in a shallow copy, and
- The local clone() implements the deep copy.
Writing a deep-copy clone is tricky.
- All constituent classes have to provide a deep-copy clone() too.

Deep-Copy Clone Example

class blob 
implements Cloneable

  public blob clone() 
  throws CloneNotSupportedException
    blob b = (blob) super.clone();
    // recursively clone instance references.
    return b;

class t
  public static void main(String args[])
    blob b = new blob();
    try blob cpy = b.clone();
    catch (Exception e) { }

The Clone Contract

Object.clone() has the contract
- x.clone() != x
- x.clone().getClass() == x.getClass()
- x.clone().equals(x) is true.
However these are not “absolute requirements”.
- Immutable instances may clone to themselves, for example.

Summary

Interfaces are lightweight abstract classes.
Favor interface types over abstract-class types.
- Use interfaces to define traits and types.
Determine copying behavior if any and override Object.clone() appropriately.
- Think hard about implementing deep copying.

References

Items 10 (Override clone judiciously), 16 (Prefer interfaces to abstract classes), and 17 (Use interfaces only to define types) from Effective Java by Joshua Bloch, Addison-Wesley, 2001.