接口优于抽象类
Java程序设计语言提供了两种机制，可以用来定义允许多个实现的类型：接口和抽象。
两种机制之间最明显的区别在：① 抽象类允许包含某个方法的实现，而接口则不允许。②为了实现由抽象类定义的类型，类必须成为抽象类的一个子类。Java只允许单继承，所以，抽象类作为类型定义受到了极大限制。
现在的类可以很容易的被更新，以实现新的接口。 如果这些方法尚不存在，你需要做的就只是增加必要的方法，然后在类的声明中增加一个implement子句。如果你希望实现两个类扩展同一个类的抽象类，就必须把抽象类放到极高的一个层次中，以便这两个类的一个祖先成为它的子类。遗憾的是，这样做会间接的伤害到类层次，迫使这个公共祖先的所有的后代类都扩展了这个新的抽象类，无论它对于这些后代类是否合适。
接口定义mixin（混合类型）的理想选择。 不严格的来讲，mixin是指这样的类型：类除了实现它的“基本类型”之外，还可以实现这个mixin类型，以表明它提供了某些可选择的行为。它允许任选的功能可以被混合到类型的主要功能中。抽象类不能够被定义为mixin，同样也是因为它们不能被更新到现有的类：类不可能有一个以上的父类。
接口允许我们构造非层次结构的类型框架。类型层次对于组织某些事物是非常合适的。但是其他有些事物并不能被整齐地组织成一个严格的层次结构。
public interface Singer{
AudioClip sing(Song s);
}
public interface Songwriter{
Song compose(boolean hit);
}
public interface SingerSongwriter extends Singer, Songwriter{
AudioClip strum();
void actSensitive();
}
你并不是总是需要这种灵活性，但是一旦你这样做了，接口可就成为了救世主，能帮助你解决大问题。另外一种做法是编写一个臃肿的类层次，对于每一种要被支持的属性组合，都包含一个单独的类。如果在整个类型系统中有n个属性，那么必须支持2^n种可能的组合。这种现象被称为“组合爆炸”。类层次的臃肿也导致类的臃肿，这些类也包含许多方法，并且这些方法只是在参数的类型上有所不同而已，因为类层次中没有任何类型体现公共的行为特征。
虽然接口不允许包含方法的实现，但是接口来定义类型并不妨碍你为程序员提供实现上的帮助。通过你导出的每个重要接口都提供一个抽象的骨架实现类（skeletal implementation）。把接口和抽象类的有点结合起来。接口的作用仍然是定义类型，但是骨架实现类接管了所有与接口实现相关的工作。
按照惯例，骨架实现被称为AbstractInterface，这里的Interface是指实现的接口的名字。例如，Collections Framework为每个重要的集合都提供了一个框架的实现，包括AbstractCollection、AbstractSet、AbstractList和AbstractMap。但它们都被称为SkeletalCollection、SkeletalSet、SkeletalList和SkeletalMap也是有道理的，但是现在Abstract的用法已经根深蒂固了。
如果涉及得当，骨架实现可以使程序员很容易提供他们自己的接口实现。例如，下面是一个静态工厂方法，它包含一个完整的、功能齐全的List实现：
// 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 ger(int i){
return a[i];
}
@Override
public Integer set(int i, Integer val){
int oldVal = a[i];
a[i] = val;
return oldVla;
}
public int size(){
return a.length;
}
}
}
当你思考一个List的实现应该为你完成那些工作的时候，可以看出，这个例子充分的演示类骨架实现的强大功能。顺便提一下，这个例子是Adapter，它允许将int数组看做Integer实例的列表。由于int值和Integer实例之间来回转换需要开销，它的性能并不会很好。注意，这个例子中只提供了一个而静态工厂，并且这个类还不可以被访问的匿名内部类，它被隐藏在静态工厂的内部。
骨架的实现上有小小的不同，就是简单实现。简单实现就像是一个骨架实现，就是因为它实现了接口，并且是为了继承而设计的但是区别在于它不是抽象的：它是最简单的有可能的有效实现。你可以原封不动的使用，也可以看情况将它子类化。
设计公有的接口要非常谨慎。接口一旦被公开发行，并且得到广泛实现，在想改变这个接口几乎是不可能的。必须在初次设计的时候保证接口是正确的。
简而言之，接口通常是定义允许多个实现类型的最佳途径。这条规则有个例外，即当演变的容易性比灵活性和功能更为重要。在这种情况下，应该使用抽象类来定义类型，但前提是必须理解并且可以被接受这些局限性。如果你导出一个重要的接口，就应该坚决考虑的同时提供骨架实现类。最后应该尽可能地设计所有的公有接口，并通过编写多个试下来对它们进行全面的测试。