Effective Java 第17条：要么为了继承而设计，并提供文档说明，要么禁止继承

        其实在 16 条中说过继承的缺点：

•  可能会导致子类很脆弱，如果超类用了自用模式并且没有提供相关的文档说明。

•  后期版本更新中，有可能导致子类实现的方法和超类中同名，从而成为覆盖父类方法。

所以设计超类的时候需要注意这些实质性的规则：

• 首先，该类的文档必须精确地描述覆盖每个方法所带来的影响。该类必须有文档说明其可改写的方法的自用性：对于每一个公有的或受保护的方法或者构造函数，它的文档必须指明它调用了哪些可改写的方法是以什么顺序调用，每个调用的结果是如何影响后续的处理过程的。　　惯例是如果一个方法调用了可改写的方法，那么在它的文档注释的末尾应该包含关于这些调用的描述信息。

• 为了使程序员能够编写出更加有效的子类，而无需承受不必要的痛苦，一个类必须通过某种形式提供适当的钩子(hook)，以便能够进入到它的内部工作流程中，这样的形式可以是精心选择的受保护方法，也可是以保护域，后者少见。　　当为了继承的目的而设计一个有可能会被广泛使用的类时，须意识到，对于文档中所说明的自用模式(self-use pattern)，以及对于其受保护方法和域所隐含的实现细节，实际上已经做出了永久的承诺。这些承诺使得你在后续的版本中提高这个类的性能或增加很功能非常困难，或者不可能。
  

• 超类的构造函数一定不能调用可改写的方法，无论是直接还是间接进行，因为超类的构造函数在子类的构造函数之前运行。
  

• 在一个为了继承而设计的类中，实现Cloneable或Serializable接口，因为clone和readObject方法在行为上非常类似于构造函数，所以无论clone还是readObject都不能调用一个可改写的方法，无论是直接还是间接的方式。　　对于readObject方法，子类中改写版本的方法将在子类的状太被反序列化之前先被运行；对于clone方法，改写版本的方法将在子类的clone方法有机会修正被克隆对象的状态之前先被运行。
  

• 在一个为了继承而设计的类中实现Serializable接口，且该类有一个readResolve或writeReplace方法，则你必须使readResolve或者writeReplace成为受保护的方法，而不是私有的方法。如果这些方法是私有的，那么子类会不声不响的忽略掉这两个方法。这正是“为了允许继承，而把实现细节变成一个类的API的一部分”的另一种情形。

最后说说这些问题的解决方案：对于那些并非为了安全的进行子类化而设计和编写文档的类，要禁止子类化。

• 声明成final 的类

• 把所有构造器的构造器都变成私有的，或者包级所有的，并增加一些共有的静态工厂来替代构造器。