代码改变世界

Effective Java 18 Prefer interfaces to abstract classes

2014-03-13 09:56  小郝(Kaibo Hao)  阅读(534)  评论(0编辑  收藏  举报

Feature

Interface

Abstract class

Defining a type that permits multiple implementations

Y

Y

Permitted to contain implementations.

N

Y

The implemented class must reside the class hierarchy.

N

Y

Single inheritance

N

Y

Easy to evolve

N

Y

   

Advantages of Interfaces

  1. Existing classes can be easily retrofitted to implement a new interface.
  2. Interfaces are ideal for defining mixins.
  3. Interfaces allow the construction of nonhierarchical type frameworks. (Composite)

    public interface Singer {

    AudioClip sing(Song s);

    }

    public interface Songwriter {

    Song compose(boolean hit);

    }

    public interface SingerSongwriter extends Singer, Songwriter {

    AudioClip strum();

    void actSensitive();

    }

  4. Interfaces enable safe, powerful functionality enhancements .
You can combine the virtues of interfaces and abstract classes by providing an abstract skeletal implementation class to go with each nontrivial interface that you export.

// Concrete implementation built atop skeletal implementation

static List<Integer> intArrayAsList(final int[] a) {

if (a == null)

throw new NullPointerException();

return new AbstractList<Integer>() {

public Integer get(int i) {

return a[i]; // Autoboxing (Item 05)

}

@Override public Integer set(int i, Integer val) {

int oldVal = a[i];

a[i] = val; // Auto-unboxing

return oldVal; // Autoboxing

}

public int size() {

return a.length;

}

};

}

Simulated multiple inheritance

The class implementing the interface can forward invocations of interface methods to a contained instance of a private inner class that extends the skeletal implementation.

// Skeletal Implementation

public abstract class AbstractMapEntry<K, V> implements Map.Entry<K, V> {

// Primitive operations

public abstract K getKey();

public abstract V getValue();

// Entries in modifiable maps must override this method

public V setValue(V value) {

throw new UnsupportedOperationException();

}

// Implements the general contract of Map.Entry.equals

@Override

public boolean equals(Object o) {

if (o == this)

return true;

if (!(o instanceof Map.Entry))

return false;

Map.Entry<?, ?> arg = (Entry<?, ?>) o;

return equals(getKey(), arg.getKey())

&& equals(getValue(), arg.getValue());

}

private static boolean equals(Object o1, Object o2) {

return o1 == null ? o2 == null : o1.equals(o2);

}

// Implements the general contract of Map.Entry.hashCode

@Override

public int hashCode() {

return hashCode(getKey()) ^ hashCode(getValue());

}

private static int hashCode(Object obj) {

return obj == null ? 0 : obj.hashCode();

}

}

Note

  1. Because skeletal implementationsare designed for inheritance, you should follow all of the design and documentation guidelines in Item 17.
  2. A minor variant on the skeletal implementation is the simple implementation. It differs by being not abstract. It's just simplest possible working implementation. You can use it as it stands or subclass it as circumstances warrant.

Summary

If you export a nontrivial interface, you should strongly consider providing a skeletal implementation to go with it. Once an interface is released and widely implemented, it is almost impossible to change. The best thing to do when releasing a new interface is to have as many programmers as possible implement the interface in as many ways as possible before the interface is frozen. Finally, you should design all of your public interfaces with the utmost care and test them thoroughly by writing multiple implementations