第18条：接口优先抽象类

Java程序设计语言提供了两种机制，可以用来定义允许多个实现的类型：接口和抽象类。这两种机制之间最明显的区别在于：

1、抽象类允许包含某些方法的实现，但是接口不允许

2、为了实现由抽象类定义的类型，类必须为抽象类的一个子类

任何一个类，只要它定义了所有必要的方法，并且遵守通用约定，它就被允许实现一个接口，而不管这个类是处于类层次（class hierarchy）的哪个位置。因为Java是单继承的，所以抽象类作为类型定义受到了极大的限制。

现有的类可以很容易被更新，以实现新的接口。如果这些方法尚不存在，你所需要做的就是增加必要的方法，然后在类的声明中增加一个implements子句。

接口是定义mixin（混合类型）的理想选择。不严格的讲，mixin是指这样的类型：类除了实现它的“基本类型（primary type）”之外，还可以实现这个mixin类型，以表达它提供了某些可供选择的行为。例如，Comparable是一个mixin接口，它允许类表明它的实例可以与其它的可相互比较的对象进行排序。这样的接口之所以被称为mixin，是因为它允许任选的功能可被混合到类型的主要功能中。抽象类不能被用于定义为mixin，同样也是因为它们不可能被更新到现有的类中：类不可能有一个以上的父类，类层次结构中也没有适当的地方来插入mixin。

接口允许我们构造非层次结构的类型框架。类型层次对于组织某些事物是非常合适的，但是其他有些事物并不能被整齐的组织成一个严格的层次结构。例如，假设我们有一个接口代表一个singer（歌唱家），另一个接口代表一个songwriter（作曲家）：

1 public interface Singer {
2     AudioClip singer(Song s);
3 }
4 public interface Songwriter {
5     Song compose(boolean hit);
6 }

在现实生活中，有些歌唱家本身也是作曲家。因为我们使用了接口而不是抽象类来定义这些类型，所以对单个类而言，它同时实现Singer和Songwriter是完全允许的。实际上，我们可以定义第三个接口，它同时扩展了Singer和Songwriter，并添加了一些适合于这种组合的新方法：

1 public interface SingerSongwriter extends Singer, Songwrite {
2     AudioClip strum();
3     void actSensitive();
4 }

你并不总是需要这种灵活性，但是一旦你这样做了，接口能帮你解决大问题。另外一种做法是编写一个臃肿（bloated）的类层次，对于每一种要被支持的属性组合，都包含一个单独的类。如果在整个类型系统中有n个属性，那么就必须支持2^n种可能的组合。这种现象被称为“组合爆炸（combinatorial explosion）”。类层次臃肿会导致类也臃肿，这种类包含许多方法，并且这些方法只是在参数的类型上有所不同而已，因为类层次中没有任何类型体现了公共的行为特征。

通过第16条中介绍的包装类（wrapper class）模式，接口使得安全的增强类的功能称为可能。如果使用抽象类来定义类型，那么程序员除了使用继承的手段来增加安全性，没有其它的选择。这样得到的类与包装类相比，功能更差，也更加脆弱。

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

按照惯例，骨架实现被称为AbstractInterface是指所实现的接口的名字。例如，Colletions Framework为每个重要的集合接口都提供了一个骨架实现，包括AbstractCollection、AbstractSet、AbstractList和AbstractMap。将它们称作SkeletalCollection、SkeletalSet、SkeletalList和SkeletalMap也是有道理的，但是现在Abstract的用法已经根深蒂固。

如果设计得当，骨架实现可以使程序员很容易地提供他们自己的接口实现。例如，下面是一个静态工厂方法，它包含一个完整的、功能齐全的List实现：

 1 static List<Integer> intArrayList(final int[] a){
 2     if (a == null)
 3         throw new NullPointerException();
 4     
 5     return new AbstractList<Integer>() {
 6         @Override
 7         public Integer get(int index) {
 8             return a[index];
 9         }
10 
11         @Override
12         public Integer set(int index, Integer element) {
13             int oldElement = a[index];
14             a[index] = element;
15             return oldElement;
16         }
17 
18         @Override
19         public int size() {
20             return a.length;
21         }
22     };
23 }

当你考虑一个List实现应该为你完成哪些工作的时候，可以看出，这个例子充分演示了骨架实现的强大功能。顺便提一下，这个例子是个Adapter，它允许将int数组看做Integer实例的列表。由于在int值和Integer实例之间来回转换需要开销，它的性能不会很好。注意，这个例子中只提供一个静态工厂，并且这个类还是不可被访问的匿名类（anonymous class），它被隐藏在静态工厂的内部。

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

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

 1 public abstract class AbstractMapEntry<K,V> implements Map.Entry<K, V>{
 2     //基本的方法
 3     public abstract K getKey();
 4     public abstract V getValue();
 5     //必须重写的方法
 6     public V setValue(V value) {
 7         throw new UnsupportedOperationException();
 8     }
 9     @Override
10     public boolean equals(Object obj) {
11         if(obj == this)
12             return true;
13         if(! (obj instanceof Map.Entry))
14             return false;
15         Map.Entry<?, ?> arg = (Map.Entry) obj;
16         return equals(getKey(), arg.getKey()) && 
17                 equals(getValue(), arg.getValue());
18     }
19     private static boolean equals(Object o1, Object o2) {
20         return o1 == null ? o2 == null : o1.equals(o2);
21     }
22     
23     @Override
24     public int hashCode() {
25         return hashCode(getKey()) ^ hashCode(getValue());
26     }
27     private static int hashCode(Object obj) {
28         return obj == null ? 0 : obj.hashCode();
29     }
30 }

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

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

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

因此，设计公有的接口要非常的谨慎。接口一旦被公开发行，并且已经被广泛实现，在想改变这个接口几乎是不可能的。

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

转载于:https://www.cnblogs.com/remote/p/10283116.html