条目18提醒你注意子类化“外来“类的危险，该类未被设计和记录用于继承。那么为类设计和记录继承是什么意思呢？
首先，类必须准确记录覆写任何方法的影响。换句话说，类必须记录它的可覆写方法的自我使用。对于每个public或protected方法，文档必须指出方法调用哪些可覆写的方法，以什么顺序，以及每个调用的结果如何影响后续处理（通过覆写，我们指的是非最终的，无论是public还是protected）。更一般地说，类必须记录它可能调用可覆写方法的任何情况。例如，调用可能来自后台线程或静态初始化程序。
调用可覆写方法的方法在其文档注释的末尾包含了这些调用的描述。描述位于规范的特殊的部分，标记为”实现要求“，由Javadoc标记@implSpect生成。本节描述了该方法的内部工作原理。这是一个从java.util.AbstractCollection规范复制的例子：
public boolean remove(Object o)
从此集合移除指定元素的单个实例（如果存在）（可选操作）。更正式地，如果这个集合包含一个或多个Objects.equals(o,e)的元素，则删除元素e。如果该集合包含指定的元素（或等效地，如果集合因调用而更改），则返回true。
实现要求：这个实现迭代集合以查找指定的元素。如果找到该元素，将使用迭代器的remove方法从集合中删除该元素。注意，如果该集合的迭代方法没有实现remove方法且此集合包含指定的对象，将抛出UnsupportedOperationException。
这个文档毫无疑问说明了覆写迭代器方法将影响remove方法的行为。它还详细描述了迭代方法返回的迭代器的行为将如何影响remove方法的行为。将此与条目18的情况对比，程序员继承HashSet根本无法说明覆写add方法是否会影响到addAll方法。
但这是不是违反了优秀的API文档应该描述给定方法的作用而不是它如何做的格言呢？是的，它确实！这是继承违反封装这一事实的一个不幸后果。要记录一个类以便于可以安全地进行子类化，你必须描述应该未指定的实现细节。
@implSpec标记在Java8中添加并在Java9中大量使用。默认情况下这个标记应该启用，但是从Java9开始，除非你执行命令行转换开关-tag "apiNote:a:API Note:"，否则Javadoc工具仍会忽略它。
为继承设计不仅仅为了记录自用模式。为了允许程序员编写有效的子类而不遭受过度痛苦，类可能必须明智地选择受保护方法为其内部工作提供钩子，或在极少数情况下，受保护字段。例如，考虑java.util.AbstractList中的removeRange方法：
protected void removeRange(int fromIndex, int toIndex)
从列表中删除索引介于fromIndex（包含）和toIndex（不含）之间的所有元素。将任何后续元素向左移动（降低它们的索引）。该调用通过（toIndex-fromIndex）元素缩短列表。（如果toIndex == fromIndex，此操作无效。）
该方法由这个列表的清除操作和它的子列表调用。覆写该方法以利用列表实现的内部方法可以显著提高此列表及其子列表上的清除操作的性能。
实现要求：该实现获取一个位于fromIndex之前的列表迭代器，并重复调用ListIterator.next ，然后调用ListIterator.remove，直到删除整个范围。注意：如果ListIterator.remove 需要线性时间，该实现需要o^2时间。
参数:
fromIndex 要被删除的第一个索引。
toIndex 要被删除的最后一个索引。
List实现的方法对于终端用户来说并不感兴趣。它仅用于使子类易于在子列表上提供快速清晰的方法。在没有removeRange方法的情况下，当子列表上调用clear方法或从头开始重写整个subList机制时，子类必须使用o^2时间复杂度-这不是一件容易的事！
那么当你设计一个类需要被继承时，如何决定什么保护成员来暴露出去？不幸的是，没有灵丹妙药。你能做的最好的事情就是努力思考，做好最好的猜测，然后通过编写子类来测试它。你应该尽可能少地暴露受保护的成员，因为每个成员代表了对实现细节的承诺。另一方面，你不能暴露太少，因为缺少受保护成员可以使一个类实际上不能用于继承。
为设计类测试的唯一方法就是编写子类。如果你忽略了一个关键的受保护成员，尝试编写子类的适合将使遗漏变得非常明显。相反，如果编写了几个子类并没有使用受保护的成员，你应该将其设为私有。经验表明，三个子类通过足以测试一个可扩展的类。这些子类的一个或更多应该由超类以外的作者来编写。
当你为继承设计一个可以广泛使用的类时，要意识到你永远承诺你所记录的自用模式以及隐含在其受保护方法和字段中的实现决策。这些承诺可能使得在后续版本中改进类的性能或功能时变得困难或不可能。因此，你必须在发布子类之前编写子类来测试它。
另请注意，继承所需要的特殊文档会使普通文档混乱，这些文档是为创建类的实例并在其上调用方法的程序员设计的。在撰写本文时，将普通API和程序员感兴趣的实现子类的信息分开的工具几乎没有。
为了允许继承，类必须遵守更多限制。构造器必须不能直接或间接调用覆写方法。如果你违反了这个规则，程序将会失败。超类构造器在子类构造器之前运行，因此子类的覆写方法将会在子类构造器调用之前运行。如果覆写方法依赖于子类构造器执行的任何初始化，该方法不会预期执行。为了使这个具体华，这是违反这个规则的一个例子：
public class Super {
// Broken - constructor invokes an overridable method
public Super() {
overrideMe();
}
public void overrideMe() {
}
}
这是一个覆写了overrideMe方法的子类，错误地调用了Super的唯一构造方法：
public final class Sub extends Super { // Blank final, set by constructor
private final Instant instant;
Sub() {
instant = Instant.now();
}
// Overriding method invoked by superclass constructor
@Override
public void overrideMe() {
System.out.println(instant);
}
public static void main(String[] args) {
Sub sub = new Sub();
sub.overrideMe();
}
}
你可能希望这个程序打印instance两次，但是它在第一次打印了null，因为在Sub构造器初始化之前调用了Super的构造器，而Super的构造器调用了overrideMe。请注意，这个程序观察了两个不同形态的final字段！另请注意，如果overrideMe在instant上调用了任何方法，当Super构造器调用overrideMe时，它会抛出NullPointerException。这个程序没有抛出NullPointerException的原因是println容许了null参数。
请注意，从构造器中调用私有方法，final方法和静态方法（任意一个都不可覆写）都是安全的。
在设计继承时，Cloneable和Serializable接口存在特殊的困难。设计用于继承的类实现这些接口中的任何一个通常不是一个好注意，因为它们给扩展类的程序员带来了沉重的负担。但是，你可以采取特殊操作来允许子类实现这些接口，而无需强制执行这些接口。这些操作在条目13(item13) 明智地覆写clone和条目86i(tem86) 中有描述。
如果你决定在一个为继承而设计的类中实现Cloneable和Serializable，你应该知道，因为clone和readObject方法的行为和构造器相似，所以适用于类似的限制：clone或readObject方法都不能直接或间接调用可覆盖的方法。对于readObject来说，覆写方法将在子类的状态被反序列化之前运行。在clone的情况下，覆写方法将在子类的clone方法有机会修复克隆状态之前运行。在任意一种情况下，都有可能出现程序故障。在克隆的情况下，失败可能会损坏原始对象和克隆对象。例如，如果覆写方法假定正在修改深层结构的克隆副本，但是尚未制作副本，就有可能发生这种情况。
最后，如果你决定在为继承而设计的类中实现Serializable，并且该类有readResolve或writeReplace方法，你必须使readResolve或writeReplace方法受保护而不是私有。如果这些方法是私有的，它们将被子类忽略。这是另一种，其实现细节成为允许继承的类的API的一部分的情况。
到目前为止，显而易见的是，设计一个继承类需要付出很大努力，并对类产生很大的限制。这不是一个轻率地决定。在某些情况下，显然这是正确地事情，比如抽象类，包括接口的骨架实现 (item20) 。在其他情况下，显然是错的，例如不可变类(item17).
但是对于普通具体类呢？传统上，它们既不是final也不是为子类化而设计和记录的，但是这种状态是危险的。每次在这样的类中进行更改，扩展类的子类都有可能会中断。这不仅仅是一个理论问题。在修改未设计和记录用于继承的非final具体类的内部之后，接口与子类相关的错误报告并不罕见。
这个问题最好的解决方案就是禁止在未设计和记录的类中进行子类化，以便安全地进行子类化。有两种方法可以禁止子类化。两者中较容易地是声明类final。另一种方法是使所有构造方法私有或包私有，用公有的静态工厂方法来代替构方法。在条目17(item17) 中讨论了这种提供内部使用子类的灵活性的替代方案。这两种方法都是可接受的。
这个建议可能有些争议，因为许多程序员早已习惯继承普通具体类来添加诸如检测，通知和同步值类的工具类或限制功能。如果一个类实现了一些捕获其本质的接口，例如Set，List，或Map，那么你应该对禁止子类化没有任何悔意。在条目18(item18) 中描述的包装类模式，提供了更好的替代方法来为继承增强功能。
如果一个具体类没有实现标准接口，那么通过禁止继承可能会给某些程序带来不便，如果你认为必须允许从这样的类中继承，一个合理的方法是确保该类永远不会调用其任何可覆写的方法并记录这个事实。换句话说，完全消除了类对可覆写方法的自我使用。这样做，你将创建一个对子类合理安全的类，覆写方法永远不会影响任何其他方法的行为。
你可以机械地消除类的可覆写方法的自我使用，而不会改变其行为。将每个可覆写方法的主体移动到私有的”辅助方法“，并让每个可覆写的方法调用其私有辅助方法。然后直接调用可覆写方法的私有辅助方法来替换可覆写方法的每个自我使用。
总结，设计一个继承类是一项辛苦的工作。你必须记录其所有的自用模式，只要你记录了，你必须在类的声明周期中保持承诺。如果你不这么做，子类可能会依赖于超类的实现细节，如果超类的实现发生更改，子类将会被破坏。为了允许其他人编写有效的子类，你可能不得不导出一个或多个受保护的方法。除非你知道确实需要子类，否则最好通过声明你的类final或确保没有可访问的构造函数来禁止继承。
本文写于2019.4.10，历时1天
