Effective Java 笔记（六）

相关读书笔记列表

NO.15 要么专门为继承而设计，并给出文档说明，要么禁止继承

 对并没有文档说明的类进行继承是非常危险的，它的公有方法有可能被改变。在设计一个专门用来继承的类时必须注意以下几点（不适用于final类）：

①必须精确地描述改写每个方法带来的影响，虽然这样的描述违法了文档格言“好的API文档应该描述一个方法做了什么工作，而不是描述它如何做”，但这也是继承破坏了程序的封装性而导致的。

②允许继承的类的构造函数一定不能调用可被改写的方法，无论是直接进行还是间接进行。因为超类的构造函数会在子类的构造函数之前运行，所以子类中改下版本的方法将会在子类的构造函数运行之前就被调用。如：

package com.ilibaba.test; import java.util.*; public class SubClass extends SuperClass { private final Date date; public SubClass() { date = new Date(); } public void m() { System.out.println(date); } public static void main(String[] args) { SubClass s = new SubClass(); s.m(); } } class SuperClass { public SuperClass() { m(); } public void m() { System.out.println("uuu"); } }

“函数一定不能调用可被改写的方法”的实现方式：把每个可改写的方法的代码体移到一个私有的“辅助方法”中，并且让每个可改写的方法调用他的私有辅助方法，然后用“直接调用可改写方法的私有辅助方法”来代替“可改写方法的每个自用调用”。

 在为了继承而设计类的时候，不推荐实现Cloneable和Serializable接口。clone和readObject方法在行为上和构造函数相似——“一定不能调用可被改写的方法，无论是直接进行还是间接进行”,对于readObject方法，子类中改写版本的方法将子类的状态被反序列化之前运行，而对于clone方法，改写版本的方法将在子类的clone方法有机会修正被克隆对象的状态之前被运行，无论哪种情形，它们都会不可避免的导致程序失败。

 对于既不是final类，也不是为了子类化而设计和编写文档的普通类而言，防止出现问题的最好方法是禁止子类化，方法有两种：

①把这个类声明为final的。

②把所有的构造函数变成私有的，或者包级私有的，并增加一个公有的静态工厂方法来代替构造函数。

继承的另一个替代方案就是利用包装类模式，具体参见NO.14 复合优先于继承

 

NO.16 接口优于抽象类

接口和抽象类的区别：

①抽象类允许包含默写方法的实现，而接口是不允许的；

②一个类要实现抽象类，它必须成为抽象类的一个子类，而实现接口的类只要定义了所要求的方法，并遵守通用的约定，不管这个类位于类层次的哪个地方；

接口可以构造出非层次结果的类型框架，比如一个接口可以继承多个其他的接口。还可以安全地增加一个类的功能。

当然，也可以把接口和抽象类的有点结合起来，对于你期望导出的每一个总要的接口，头提供一个抽象的骨架实现类，这样，接口的作用仍然是定义类型，骨架实现类负责所以与接口实现相关的工作。

抽象类也有明显的优势，它可以在一个类的后续的版本中方便的增加一个新的方法，但不影响到其他相关的类，而接口则做不到这一点。

总之，接口通常是定义具有多个实现类型的最佳途径（例外的情况：当演化的容易性比灵活性和功能更为重要的时候，应该使用抽象类来定义类型，但也必须理解抽象类的局限性，并确保可以接受这些局限性），如果已经导出了一个重要的接口，那么，也应该考虑同时提供一个骨架实现类。最后，应该尽可能的谨慎设计所有的公有接口，并通过编写多个实现来对它们进行全面的测试。

 

NO.17 接口只是被用于定义类型

接口只是用来定义一个类型，不要把接口用来做其他的事情（如在接口中定义常量，这种常量接口模式是对接口的不良使用）。

如果要导出常量，可以有以下几种方式：

①如果这些常量与某个已有的类或者接口有着紧密的联系，则可以把常量添加到这个类或者接口中。

②定义一个类型安全的枚举类，把这些常量看做枚举类型的成员。

③使用一个可以实例化的工具类（构造函数设为privat类型）来导出这些常量。