Effective Java笔记第三章类和接口第六节接口优于抽象类

Effective Java笔记第三章类和接口

第六节接口优于抽象类

1.java程序设计语言提供了两种机制，可以用来定义允许多个实现的类型：接口和抽象类。这两种机制之间最明显的区别在于，抽象类允许包含某些方法的实现，但是接口则不允许，一个更为重要的区别在于，为了实现由抽象类定义的类型，类必须成为抽象类的一个子类。任何一个类，只要它定义了所有必要的方法，并且遵守通用约定，他就被允许实现一个接口，而不管这个类是处于类层次的哪个位置。因为java只允许单继承，所以，抽象类作为类型定义受到了极大的限制。

2.现有的类可以很容易被更新，以实现新的接口。如果这些方法尚不存在，你所需要做的就只是增加必要的方法，然后在类的声明中增加一个implements子句。一般来说，无法更新现有的类来扩展新的抽象类。如果你希望让两个类扩展同一个抽象类，就必须把抽象类放到类型层次的高处，以使这两个类的一个祖先成为他的子类。遗憾的是，这样做会间接地伤害到类层次，迫使这个公共祖先的所有后代类都扩展这个新的抽象类，无论它对于这些后代类是否合适。

3.接口是定义mixin（混合类型）的理想选择。不严格的讲，mixin是指这样的类型：类除了实现他的"基本类型"之外，还可以实现这个mixin类型，以表明它提供了某些可供选择的行为。抽象类不能被用于定义mixin，同样也是因为他们不能被更新到现有的类中：类不可能有一个以上的父类，类层次结构中也没有适当的地方来插入mixin。

4.接口允许我们构造非层次结构的类型框架。类型层次对于组织某些事物是非常合适的，但是其他有些事物并不能被整齐的组织成一个严格的层次结构。下面我们举个例子：

public interface Singer{

    AudioClip sing(String s);

}

public interface Songwriter {

     void write();

}

public interface SingerSongwriter extends Singer ,Songwriter {

    @Override
    AudioClip sing(String s);

    @Override
    void write();

}

5.包装类模式，接口使得安全地增强类的功能成为可能。如果使用抽象类来定义类型，那么程序员除了使用继承的手段来增强功能，没有其他的选择。这样得到的类与包装类相比，功能更差，也更加脆弱。

6.虽然接口不允许包含方法的实现，但是，使用接口来定义类型并不妨碍你为程序员提供实现上的帮助。通过对你导出的每个重要接口都提供一个抽象的骨架实现类，把接口和抽象类的优点结合起来。接口的作用仍然是定义类型，但是骨架实现类接管了所有与接口实现相关的工作。下面我们举个例子：

public class ListDemo {

    static List<Integer> intArrayAsList(final int[] a){
        if(null==a){
            throw new NullPointerException();
        }
        //AbstractList实现了List接口，是个抽象类，是List接口的抽象骨架实现。
        return new AbstractList<Integer>() {
            @Override
            public Integer get(int i) {
                return a[i];
            }

            @Override
            public Integer set(int i, Integer val) {
                int voldVal=a[i];
                a[i]=val;
                return voldVal;
            }

            @Override
            public int size() {
                return a.length;
            }
        };
    }

}

7.骨架实现的美妙之处在于，他们为抽象类提供了实现上的帮助，但又不强加"抽象类被用作类型定义时"所特有的严格限制。对于接口的大多数实现来讲，扩展骨架实现类是个很显然的选择，但并不是必需的。如果预置的类无法扩展骨架实现类，这个类始终可以手工实现这个接口。此外，骨架实现类仍然能够有助于接口的实现。实现了这个接口的类可以把对于接口方法的调用，转发到一个内部私有类的实例上，这个内部私有类扩展了骨架实现类。这种方法被称作模拟多重继承。这项技术具有多重继承的绝大多数优点，同时又避免了相应的缺陷。

8.编写骨架实现类相对比较简单，只是有点单调乏味。首选必须认真研究接口，并确定哪些方法是最为基本的，其他的方法则可以根据他们来实现。这些基本方法将成为骨架实现类中抽象方法。然后，必须为接口中其他的方法提供具体的实现。下面我们写个Map.Entry接口的骨架实现类：
Map.Entry接口部分源码

public interface Map<K,V> {
	interface Entry<K,V> {
		K getKey();
		V getValue();
		V setValue(V value);
		int hashCode();
	}
}

骨架实现类

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

    //最基本的方法作为抽象方法
    public abstract K getKey();
    //最基本的方法作为抽象方法
    public abstract V getValue();
    //其他方法提供具体的实现
    @Override
    public V setValue(V value) {
        throw new UnsupportedOperationException();
    }

    @Override
    public boolean equals(Object o) {
        if (o == this) {
            return true;
        }
        if (!(o instanceof Map.Entry)) {
            return false;
        }
        Map.Entry<?, ?> arg = (Map.Entry) o;
        return equals(getKey(), arg.getKey()) && equals(getValue(), arg.getValue());
    }

    private static boolean equals(Object o1, Object o2) {
        return null == o1 ? null == o2 : o1.equals(o2);
    }

    @Override
    public int hashCode() {
        return hashCode(getKey()) ^ hashCode(getValue());
    }

    private static int hashCode(Object o) {
        return null == o ? 0 : o.hashCode();
    }


}

9.骨架实现上有个小小的不同，就是简单实现。简单实现就像个骨架实现，这是因为他实现了接口，并且是为了继承而设计的，但是区别在于它不是抽象的：它是最简单的可能的有效实现。你可以原封不动地使用，也可以看情况将他子类化。

10.使用抽象类来定义允许多个实现的类型，与使用接口相比有一个明显的优势：抽象类的演变比接口的演变要容易得多。如果在后续的发行版本中，你希望在抽象类中增加新的方法，始终可以增加具体方法，它包含合理的默认实现。然后，该抽象类的所有现有实现都将提供这个新的方法。对于接口，这样做是行不通的。

11.一般来说，要想在公有接口中增加方法，而不破坏实现这个接口的所有现有的类，这是不可能的。之前实现该接口的类将会漏掉新增的方法，并且无法再通过编译。在为接口增加新方法的同时，也为骨架实现类增加同样的新方法，这样可以在一定程度上减小由此带来的破坏，但是，这样做并没有真正解决问题。所有不从骨架实现类继承的接口实现仍然会遭到破坏。

12.设计公有的接口要非常谨慎，接口一旦被公开发行，并且已被广泛实现，再想改变这个接口几乎是不可能的。你必须在初次设计的时候就保证接口是正确的。

13.简而言之，接口通常是定义允许多个实现的类型的最佳途径。这条规则有个例外，即当演变的容易性比灵活性和功能更为重要的时候。在这种情况下，应该使用抽象类来定义类型，但前提是必须理解并且可以接受这些局限性。如果你导出了一个重要的接口，就应该坚决考虑同时提供骨架实现类。最后，应该尽可能谨慎的设计所有的公有接口，并通过编写多个实现来对他们进行全面的测试。