Effective Java 类和接口 第18条：接口优于抽象类
java程序设计语言提供了两种机制，可以用来定义允许多个实现的类型：接口和抽象类。这两种机制之间最明显的区别在于，抽象类允许包含某些方法的实现，但是接口不允许，一个更重要的区别在于，为了实现抽象定义的类型，类必须成为抽象类的子类，任何一个类，只要它定义了所有必要的方法，并且遵守通用约定，它就被允许实现一个接口，而不管这个类是处于类层次的那个位置。可以Java只允许单继承，所以抽象类作为类型定义受到了极大的限制。
现有的类可以很容易被更新，以实现新的接口。
如果这些方法尚不存在，你需要做的就只是增加必要的方法，然后在类的声明中增加一个implement子句。
如果你希望实现两个类扩展同一个类的抽象类，就必须把抽象类放到类型层次的高处，以便这两个类的一个祖先成为它的子类。遗憾的是，这样做会间接的伤害到类层次，迫使这个公共祖先的所有的后代类都扩展了这个新的抽象类，无论它对于这些后代类是否合适。
接口是定义mixin（混合类型）的理想选择。
不严格的来讲，mixin是指这样的类型：类除了实现它的“基本类型”之外，还可以实现这个mixin类型，以表明它提供了某些可选择的行为。这样的接口之所以被称为mixin，是因为它允许任选的功能可被混合到类型的主要功能中。抽象类不能够被定义为mixin，同样也是因为它们不能被更新到现有的类：类不可能有一个以上的父类，类层次结构中也没有适当的地方来插入mixin。
接口允许我们构造非层次结构的类型框架。
类型层次对于组织某些事物是非常合适的。但是其他有些事物并不能被整齐地组织成一个严格的层次结构。
例：假设我们有一个接口代表一个singer，另一个接口代表一个songweiter。
public interface Singer{
AudioClip sing(Song s);
}
public interface Songwriter{
Song compose(boolean hit);
}在现实生活中，有些歌唱家本身也是作曲家。因为我们使用了接口而不是抽象类来定义这些类型，所以对于单个类而言，它同时实现Singer和Songwriter是允许的，实际上我们可以定义第三个接口，他同时扩展了Singer和Songwriter，并添加了一些适合于这种组合的新方法：
public interface SingerSongwriter extends Singer, Songwriter{
AudioClip strum();
void actSensitive();
}
你并不是总是需要这种灵活性，但是一旦你这样做了，接口可就成为了救世主，能帮助你解决大问题。另外一种做法是编写一个臃肿的类层次，对于每一种要被支持的属性组合，都包含一个单独的类。如果在整个类型系统中有n个属性，那么必须支持2^n种可能的组合。这种现象被称为“组合爆炸”。类层次的臃肿也导致类也臃肿，这些类也包含许多方法，并且这些方法只是在参数的类型上有所不同而已，因为类层次中没有任何类型体现公共的行为特征。
通过第16条中介绍的包装类模式，接口是个安全的增加类的功能称为可能。如果使用抽象类来定义类型，那么程序员除了使用继承的手段来增加功能，没有其他的选择，这样得到的类与包装相比，功能更差，也更加脆弱。
虽然接口不允许包含方法的实现，但是接口来定义类型并不妨碍你为程序员提供实现上的帮助。通过对你导出的每个重要接口都提供一个抽象的骨架实现类。把接口和抽象类的优点结合起来。接口的作用仍然是定义类型，但是骨架实现类接管了所有与接口实现相关的工作。
按照惯例，骨架实现被称为AbstractInterface，这里的Interface是指所是实现的接口的名字。例如Collections、Framework为每个重要的集合接口都提供了一个骨架实现，包括AbstractCollection、AbstractSet、AbstractList和AbstractMap。将他们称作SkeletalCollection、SkeletalSeet、SkeletalList和SkeletalMap也是有道理的，但是现在Abstract的用法已经根深蒂固。
如果设计得当，骨架实现可以使程序员很容易提供他们的接口实现。
例：一个静态工厂方法，它包括一个完整的，功能全面的List实现：
//Concrete implementation built atop skeletak implementation
static List intArrayAsList(final int[] a){
if(a == null )
throw new NullPointerException();
return new AbstractList(){
public Integer get(int i){
return a[i];//Autoboxing (Item s)
}
@Override
public Integer set(int i,Integer val){
int oldVal=a[i];
a[i]=val;//Anto-unboxing
return oldVal;//Antoboxing
}
public int size(){
return a.length;
}
};
} 当你考虑一个List实现应该为你完成那些工作的时候，可以看出，这个例子充分演示了骨架实现的强大功能。
骨架实现的美妙之处在于，它们为抽象类提供了实现上的帮助，但又不强加“抽象类被用作类型定义时”所特有的严格限制。对于接口的大多数实现来讲，扩展骨架实现类是个很明显的选择，但不是必须的。如果预置的类无法扩展骨架实现类，这个类始终可以手工实现这个接口。此外，骨架实现类仍然能够有助于接口的实现。实现这个接口的类可以把对于接口方法的调用，转发到一个内部私有类的实例上，这个内部私有类扩展了骨架实现类。这种方法被称作模拟多态继承，它与第16条中讨论的包装类模式密切相关。这项技术具有多重继承的绝大多数有点，同时又避免了相应的缺陷。
编写骨架实现类相对比较简单，只是有点单调乏味。首先，必须认真研究接口，并确定哪些方法是最为基本的，其他方法则可以根据它们来实现。这些基本方法将成为骨架实现类中的抽象方法。然后，必须为接口中的所有其他的方法提供具体实现。
例：Map.Entry接口的骨架实现类
public abstract class AbstractMapEntry implements Map.Entry {
//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 obj) {
if (obj == this) {
return true;
}
if (!(obj instanceof Map.Entry)) return false;
Map.Entry arg = (Map.Entry) obj;
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.equals
@Override
public int hashCode() {
return hashCode(getKey()) ^ hashCode(getValue());
}
private static int hashCode(Object obj) {
return obj == null ? 0 : obj.hashCode();
}
} **因为骨架实现类是为了继承的目的而设计的，所以应该遵守第17条中介绍的所有关于设计和文档的指导原则。
骨架实现有个小小不的不同，就是简单实现（simple implementation），**AbstractMap.SimpleEntry就是个例子。简单实现就像个骨架实现，这是因为它实现了接口，并且是为了继承而设计的，但是区别在于它不是抽象的：它是最简单的可能的有效实现。你可以原封不动的使用，也可以看情况将它子类化。
抽象类相对于接口有一个优势：抽象类的演变比接口的演变要容易的多。如果在后续的发行版本中，你希望在抽象类中增加新的方法，始终可以增加具体方法，它包含合理的默认实现。然后，该抽象类的所有实现都将提供这个新的方法。对于接口，这样做是行不通的。因此设计共有接口要非常谨慎，接口一旦被公开发行，并且已被广泛实现，在想改变这个接口几乎是不可能的。