第18条~第19条

第18条：接口优于抽象类

众所周知，java中提供了接口和抽象类两种机制来定义允许多个实现的类型，这一条主要就在讨论这两者之间的优劣。

相比于抽象类而言，接口会更加的灵活，如果一个类需要扩展一个新的接口，那么只需要多增加一个接口的实现即可。但是抽象类就无法这么做，因为java语言中不允许多继承，而且在抽象类中增加一个抽象方法会影响到实现它的所有子类，所以扩展抽象类的抽象方法需要格外的慎重。

接口的灵活性还体现在一个方面，就是接口可以相互的组合，可以举出一个例子，一个物品可能有三种形状，三种颜色，三种材质，想要例举出所有的可能，如果使用抽象类来实现，那么需要定义3的3次方，即27种抽象类，但是如果使用接口来实现，则只需要为每一种属性定义接口，即9个接口，在使用的时候相互组合就可以了。

而且使用抽象类容易引起层次结构的混乱，因为一个类想要实现一个抽象类，那么这个抽象类就必然的被插入到这个类的层级结构中，即使这两者之间并没有明显的层级关系。

但是抽象类具有一个接口所没有的优点，那就是抽象类中可以包含方法的实现，而且对于这些内部实现的修改，可以在不修改子类的情况下进行。

总而言之，一般情况下，接口是定义允许多个实现的类型的最佳途径，但是，当内部实现的演变性相较于灵活性更为重要的时候，就应该使用抽象类来定义类型。

在书中还提出了骨架实现类这样的方案，即使用接口来定义类型，并使用骨架实现类（抽象类）来进行部分方法的实现工作，这样就可以把接口与抽象类两者的优点相结合。

第19条：接口只用于定义类型

一般来说，接口代表着实现这个接口的类的抽象类型，所以为了其它的目的定义接口的行为都是不恰当的。

一个非常常见的例子就是常量接口，这种接口中不包含任何方法，只包含一个或多个常量。如果这样做，其它的类只需要实现这个接口就可以直接使用其中的常量而避免加上类名的修饰。

但是作者对此的观点是：常量接口模式是对接口的不良使用，因为如果这么做会将接口中的常量泄露至导出的API文档中，而且这个类所有的子类也会被这些常量所“污染”。虽然java的源码中也存在常量接口，但这些接口应该被视为反面典型，不应效仿。