ITEM 64: REFER TO OBJECTS BY THEIR INTERFACES
Item 51 规定应该使用接口而不是类作为参数类型。更一般地说，您应该优先使用接口而不是类来引用对象。如果存在适当的接口类型，那么应该使用接口类型声明参数、返回值、变量和字段。只有在使用构造函数创建对象时，才真正需要引用对象的类。具体来说，考虑 LinkedHashSet 的情况，它是 Set 接口的一个实现。养成这样打字的习惯:
// Good - uses interface as type
Set<Son> sonSet = new LinkedHashSet<>();
而不是：
// Bad - uses class as type!
LinkedHashSet<Son> sonSet = new LinkedHashSet<>();
如果您养成了使用接口作为类型的习惯，那么您的程序将会更加灵活。如果您决定要切换实现，您所要做的就是更改构造函数中的类名(或使用不同的静态工厂)。例如，第一个声明可以改为:
Set<Son> sonSet = new HashSet<>();
那么，为什么要更改实现类型呢？因为第二个实现比原来的实现提供了更好的性能，或者因为它提供了原来的实现所缺少的功能。例如，假设一个字段包含一个HashMap 实例。将其更改为 EnumMap 将提供更好的性能和与键的自然顺序一致的迭代顺序，但是您只能在键类型为 enum 类型的情况下使用 EnumMap。将 HashMap 更改为 LinkedHashMap 将提供可预测的迭代顺序，性能与 HashMap 相当，而不需要对键类型进行任何特殊要求。
您可能认为使用变量的实现类型声明变量是可以的，因为您可以同时更改声明类型和实现类型，但是不能保证这种更改会导致编译程序。如果客户端代码对原始实现类型使用了在替换时不存在的方法，或者如果客户端代码将实例传递给需要原始实现类型的方法，那么在进行此更改后，代码将不再编译。使用接口类型声明变量可以使您保持诚实。
如果没有合适的接口存在，那么通过类而不是接口来引用对象是完全合适的。例如，考虑值类，如 String 和 BigInteger。在编写值类时，很少考虑到多个实现。它们通常是 final 的，很少有相应的接口。将这样的值类用作参数、变量、字段或返回类型非常合适。
没有适当接口类型的第二种情况是属于框架的对象，其基本类型是类而不是接口。如果一个对象属于这样一个基于类的框架，那么最好通过相关的基类(通常是抽象的)来引用它，而不是通过它的实现类。许多像 OutputStream 这样的 java.io 类就属于这一类。
最后一种没有合适接口类型的情况是，类实现了一个接口，但同时又提供了在接口中找不到的额外方法——例如，PriorityQueue 有一个在队列接口上不存在的比较器方法。只有当程序依赖于额外的方法时，才应该使用这样的类来引用它的实例，这种情况应该非常少见。
这三种情况并不是要面面俱到，而仅仅是为了表达通过类引用对象是适当的情况。在实践中，给定对象是否具有适当的接口是很明显的。如果是这样，如果使用接口引用对象，则程序将更灵活、更时尚。如果没有合适的接口，只需使用类层次结构中提供所需功能的最不特定的类。
