Effective Java 第三版——64. 通过对象的接口引用对象

Tips
书中的源代码地址：https://github.com/jbloch/effective-java-3e-source-code
注意，书中的有些代码里方法是基于Java 9 API中的，所以JDK 最好下载 JDK 9以上的版本。

Effective Java, Third Edition

64. 通过接口引用对象

条目 51中指出，应该使用接口而不是类作为参数类型。更通常地说，应该更喜欢使用接口而不是类来引用对象。如果存在适当的接口类型，那么应该使用接口类型声明参数、返回值、变量和属性。真正需要引用对象的类的惟一时机是使用构造方法创建它的时候。为了具体说明这一点，考虑LinkedHashSet的情况，它是Set接口的一个实现。养成这样的习惯:

// Good - uses interface as type
Set sonSet = new LinkedHashSet<>();

不要是下面这个样子：

// Bad - uses class as type!
LinkedHashSet sonSet = new LinkedHashSet<>();

如果养成了使用接口作为类型的习惯，那么你的程序将更加灵活。如果决定要切换实现，只需在构造方法中更改类名(或使用不同的静态工厂)。例如，第一个声明可以改为:

Set sonSet = new HashSet<>();

所有的代码都会继续工作。周围的代码不知道旧的实现类型，所以它不会注意到这一变化。

有一点需要注意：如果原始实现提供了接口的常规约定不需要的某些特殊功能，并且代码依赖于该功能，那么新实现提供相同的功能至关重要。 例如，如果围绕第一个声明的代码依赖于LinkedHashSet的排序策略，那么在声明中用HashSet替换LinkedHashSet是不正确的，因为HashSet不保证迭代顺序。

那么，为什么要更改实现类型呢？因为第二个实现比原来的实现提供了更好的性能，或者因为它提供了原来的实现所缺乏的理想功能。例如，假设一个属性包含一个HashMap实例。将其更改为EnumMap将提供更好的性能和与键的自然顺序一致的迭代顺序，但是只能在键类型为枚举类型的情况下使用EnumMap。将HashMap更改为LinkedHashMap将提供可预测的迭代顺序，性能与HashMap相当，而不需要对键类型作出任何特殊要求。

你可能认为使用变量的实现类型声明变量是可以的，因为可以同时更改声明类型和实现类型，但是不能保证这种更改能否正常编译。如果客户端代码对原始实现类型使用了替换时不存在的方法，或者客户端代码将实例传递给需要原始实现类型的方法，那么在进行此更改之后，代码将不再编译。使用接口类型声明变量可以保持诚实可靠。

如果不存在适当的接口，则通过类而不是接口引用对象是完全合适的。 例如，考虑值类，例如String和BigInteger。 值类很少用多个实现类来编写。 它们通常是final的，很少有相应的接口。 将这样的值类用作参数，变量，属性或返回类型是完全合适的。

没有适当接口类型的第二种情况是属于框架的对象，其基本类型是类而不是接口。 如果一个对象属于这样一个基于类的框架，最好用相关的基类来引用它，它通常是抽象类，而不是它的实现类。 许多java.io包下的类（如OutputStream）都属于此类。

没有适当接口类型的最后一种情况是实现接口的类，但也提供了在接口中找不到的额外方法——例如，PriorityQueue具有Queue接口上不存在的comparator方法。 只有当程序依赖于额外的方法时，才应该使用这样的类来引用它的实例，这种情况应该是非常少见的。

这三种情况并不是面面俱到的，而仅仅是为了传达通过合适的类引用对象的情况。在实践中，给定对象是否具有适当的接口应该是显而易见的。如果是这样，使用接口引用对象，程序将更加灵活和流行。如果没有合适的接口，就使用类层次结构中提供所需功能的最小的具体类。