Effective Java(3rd)-Item21 为后代设计接口

  在Java8之前，不可能在不破坏现有实现的情况下向接口添加方法。如果在接口中添加新方法，通常现有的实现缺少该方法，会导致编译错误。在Java8中，添加了默认方法构造[JLS 9.4]，目的是允许向现有接口添加方法。但是在现有接口添加新方法充满了危险。
  默认方法的声明包括默认实现，该实现由实现该接口但未实现该默认方法的所有类使用。虽然向Java添加默认方法可以将方法添加到现有接口，但是不能保证在所有实现中都能正常工作。默认方法在未经实现者知晓或同一的情况下“注入”现有实现。在Java8之前，这些实现是在默认情况下编写的，它们的接口永远不会获得任何新方法。
  Java8的核心集合接口中添加了许多默认方法，主要是为了lambda的使用（章节6）。Java库的默认方法是高质量的通用实现，在大多数情况下，它们工作正常。但是并不总是可以编写一个默认方法来维护每个可想到的实现的所有不变量。
  例如，考虑removeIf方法，该方法在Jaba8中被加入Collection接口中。该方法移除所有给定布尔函数（或断言）返回true的元素。指定默认实现使用其迭代器遍历集合，在每个元素上调用断言，并使用迭代器的remove方法移除断言为true的元素。想必声明看起来像这样：

image.png

  这可能是为removeId方法编写的最佳通用实现，但是遗憾的是，它在一些真实的Collection实现上失败了。比如，考虑org.apache.commons.collections4.collection.SynchronizedCollection。这个类，来自Apache Commons库，与java.util中的静态工厂Collections.synchronizedCollection 返回的类相似。Apache版本还提供了使用客户端提供的对象进行锁定的能力，而不是集合。换句话说，它是一个包装类（item18） ，其所有方法在委托给包装集合之前在锁定对象上同步。
  Apache SynchronizedCollection类仍在积极维护，但是在撰写本文时，它并没有覆写removeIf方法。如果这个类与Java8一起使用，它将因此继承removeIf的默认实现，但它实际上不能维护类的基本承诺：自动同步每个方法的调用。默认实现对同步一无所知，并没有权限方便包含锁定的对象。如果一个客户端在另一个线程同时修改集合的情况下在SynchronizedCollection实例上调用removeIf方法，则可能会导致ConcurrentModificationException或其他未指定的行为。
  为了阻止类似的Java平台库实现中发生这种情况，例如通过Collections.synchronizedCollection返回的包私有类，JDK维护者必须覆写默认的removeIf实现和其他类似的方法，以便在调用默认实现之前执行必要的同步。不属于Java平台的预先存在的集合实现没有机会通过接口更改来锁定类似的更改，有些还没有这样做。
  在存在默认方法的情况下，接口的现有实现可以在没有错误或警告的情况下编译，但在运行时失败。虽然不是非常普遍，但是这个问题也不是一个孤立的实现。已知添加到Java8中的集合接口的少数方法易受影响，并且已知少数现有实现受到影响。
  除非需要是关键的，否则应该避免使用默认方法向现有接口添加新方法，在这种情况下，你应该仔细考虑现有接口实现是否可能被默认方法实现破坏。但是，默认方法对于在创建接口时提供标准方法实现非常有用，以简化实现接口的任务（item20）。
  还值得注意的时，默认方法并非旨在支持从接口中删除方法或更改现有方法的签名。在不破坏现有客户端的情况下，这些接口更改都不可能。
  道德很清楚。即使默认方法现在是Java平台的一部分，但是设计接口仍然非常重要。即使默认方法可以将方法添加到现有接口，但是这样做的风险很大。如果接口包含一个小缺陷，它可能会永远激怒它的用户；如果接口严重匮乏，可能会使包含它的API失效。
  因此，在你发布之前，测试每个新接口都是至关重要的。多个程序员应该以不同的方式实现每个接口。至少，你应该针对三种不同的实现。同样重要的是编写多个客户端程序，使用每个新接口的实例来执行各种任务。这将大大有助于确保每个接口满足其所有预期用途。这些步骤将允许你在发布之前发现接口中的缺陷，当你还能更正它们的时候。虽然发布接口之后你可以纠正一些接口缺陷，但是你不能指望它。
本文写于2019.4.15，历时1天