接口优于抽象类。

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

• 现有的类可以很容易被更新。以实现新的接口。
• 接口是定义mixin（混合类型）的理想选择。
• 接口允许我们构造非层次结构的类型框架。

通过对你导出的每个重要接口都提供一个抽象的骨架实现（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> intArrayList(final int[] a) {

if (a == null) {

throw new NullPointerException();

}

return new AbstractList<Integer>() {

public Integer get(int i) {

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

}

@Override 

public Integer set( int i , Integer val) {

int oldVal = a[i];

a[i] = val; // Auto_unboxing

return oldVal; // Autoboxing

}

@Override

public int size() {

return a.length();

}

}

}

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

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

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

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

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

因此，设计公有的接口要非常谨慎。接口一旦被公开发行，并且已被广泛实现，再想改变这个接口几乎是不可能的。你必须在初次设计的时候就保证接口是正确的。如果接口包含微小的瑕疵，他将会一直影响你以及接口的用户。如果接口具有严重的缺陷，他可以导致API彻底失败。在发行新接口的时候，最好的做法是，在接口被“冻结”之前，尽可能让更多的程序员用尽可能多的方式来实现这个新接口。这样有助于在依然可以改正缺陷的时候就发现他们。

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