Effective Java读书笔记---四、类和接口

四、对于所有对象都通用的方法

15.使类和成员的可访问性最小化

区分一个组件设计得好不好，唯一重要的因素在于，它对于外部的其他组件而言，是否隐藏了其内部数据和其他实现细节。

信息隐藏 -----> 解耦
- 访问控制机制协助信息隐藏 --> 规则：尽可能地使每个类或者成员不被外界访问
  - private：只有在声明该成员的顶层类内部才可以访问这个成员
  - package-private：声明该成员的包内部的任何类都可以访问这个成员-default
  - protected：声明该成员的类的子类可以访问这个成员（但有一些限制），并且声明该成员的包内部的任何类也可以访问这个成员。
  - public：在任何地方都可以访问该成员。
除了公有静态 final 域的特殊情形之外（此时它们充当常量），公有类都不应该包含公有域，并且要确保公有静态 final 域所引用的对象都是不可变的。
封装

16.要在公有类而非公有域中使用访问方法

如果类可以在它所在的包之外进行访问，就提供访问方法
如果类是包级私有的，或者是私有的嵌套类，直接暴露它的数据域并没有本质的错误

17.使可变性最小化

不可变类是指其实例不能被修改的类。每个实例中包含的所有信息都必须在创建该实例的时候就提供，并在对象的整个生命周期（ lifetime ）内固定不变 .

规则：

不要提供任何会修改对象状态的方法
保证类不会被扩展。声明这个类成为 final 的
声明所有的域都是 fi nal 的
声明所有的域都为私有的
确保对子任何可变组件的互斥访问。

不可变对象

不可变对象比较简单
不可变对象本质上是线程安全的，它们不要求同步
不可变对象可以被自由地共享 ---- 不仅可以共享不可变对象，甚至也可以共享它们的内部信息。
不仅可以共享不可变对象，甚至也可以共享它们的内部信息。
不可变对象为其他对象提供了大量的构件
不可变对象无偿地提供了失败的原子性
不可变类真正唯一的缺点是，对于每个不同的值都需要一个单独的对象。

public final class Complex {private final double re;private final double im;public Complex(double re, double im) {this.re = re;this.im = im;}public double realPart(){return re;}public double imaginaryPart(){return im;}//......}

不可变的类变成 final 的另一种办法（更加灵活）就是，让类的所有构造器都变成私有的或者包级私有的，并添加公有的静态工厂（ static factory ）来代替公有的构造器

package efffect;public final class Complex {private final double re;private final double im;private Complex(double re, double im) {this.re = re;this.im = im;}public static Complex valueOf(double re, double im){return new Complex(re, im);}
}

坚决不要为每个 get 方法编写一个相应的 set 方法。除非有很好的理由要让类成为可变的类，否则它就应该是不可变的

如果类不能被做成不可变的，仍然应该尽可能地限制它的可变性。

构造器应该创建完全初始化的对象，并建立起所有的约束关系

通过 CountDownLatch 类的例子可以说明这些原则。它是可变的，但是它的状态空间被有意地设计得非常小。比如创建一个实例，只使用一次，它的任务就完成了：一旦定时器的计数达到零，就不能重用了。

18.复合优先于继承

继承打破了封装性，最严重的是，客户有可能直接修改超类，从而破坏子类的约束条件。

只有当子类真正是超类的子类型（ subtyp巳）时，才适合用继承。

19.要么设计继承并提供文档说明，要么禁止继承

要么设计继承并提供文档说明，要么禁止继承

类必须以精心挑选的受保护的（ protected ）方法的形式，提供适当的钩子（ hook ），以便进入其内部工作中

对于为了继承而设计的类，唯一的测试方法就是编写子类。

构造器决不能调用可被覆盖的方法，无论是直接调用还是间接调用。如果违反了这条规则，很有可能导致程序失败。超类的构造器在子类的构造器之前运行，所以，子类中覆盖版本的方法将会在子类的构造器运行之前先被调用。如果该覆盖版本的方法依赖于子类构造器所执行的任何初始化工作，该方法将不会如预期般执行。 (通过构造器调用私有的方法、 final 方法和静态方法是安全的，这些都不是可以被覆盖的方法。 )

无论是 clone 还是readObject ，都不可以调用可覆盖的方法，不管是以直接还是间接的方式。

对于 readObject 方法，覆盖的方法将在子类的状态被反序列化（ deserialized ）之前先被运行；
对于 clone 方法，覆盖的方法则是在子类的clone 方法有机会修正被克隆对象的状态之前先被运行。无论哪种情形，都不可避免地将导致程序失败。在 clo口e 方法的情形中，这种失败可能会同时损害到原始的对象以及被克隆的对象本身。

如果你决定在一个为了继承而设计的类中实现 Serializable 接口，并且该类有一个 readResolve 或者 writeReplace 方法，就必须使 readResolve 或者 write Replace 成为受保护的方法，而不是私有的方法。

结论：为了继承而设计类，对这个类会有一些实质性的限制；对于那些并非为了安全地进行子类化而设计和编写文档的类，要禁止子类化。

方法：

把这个类声明为fina l 的。
把所有的构造器都变成私有的，或者包级私有的，并增加一些公有的静态工厂来替代构造器。

20.接口优于抽象类

现有的类可以很容易被更新，以实现新的接口。

接口是定义 mixin （混合类型）的理想选择

接口允许构造非层次结构的类型框架。

假设我们有一个接口代表一个 singer （歌唱家），另一个接口代表一个 songwriter （作曲家）

public interface Singer{}
public interface Songwriter{}

有些歌唱家本身也是作曲家，定义新接口，扩展—但如果很多会很臃肿

public interface SingerSongwriter extends Singer, Songwriter{}

通过对接口提供一个抽象的骨架实现类，可以把接口和抽象类的优点结合起来，接口负责定义类型，骨架实现类负责实现除基本类型接口方法之外，剩下的非基本类型接口方法。

例如，Collections Framework为每个重要的集合接口都提供了一个骨架实现，包括AbstractCollection，AbstractSet，将他们称作SkeletalCollection，SkeletalSet

实现方法:

认真研究接口，确定哪些方法是最基本的，其他方法则可以根据他们来实现，这些基本方法将成为骨架实现类中的抽象方法。
在接口中为所有可以在基本方法之上直接实现的方法提供缺省方法，但不能为object方法提供缺省方法。

对于骨架实现类而言，好的文档绝对是非常必要的，

接口通常是定义允许多个实现的类型的最佳途径。如果你导出了一个重要的接口，就应该坚决考虑同时提供骨架实现类。而且，还应该尽可能地通过缺省方法在接口中提供骨架实现，以便接口的所有实现类都能使用。

21.为后代设计接口

建议尽量避免利用缺省方法在现有接口上添加新的方法，除非有特殊需要，但就算在那样的情况下也应该慎重考虑：缺省的方法实现是否会破坏现有的接口实现

22.接口只用于定义类型

常量接口模式是对接口的不良使用

接口应该只被用来定义类型，它们不应该被用来导出常量。

23.类层次优于标签类

有时可能会遇到带有两种甚至更多种风格的实例的类，并包含表示实例风格的标签( tag ）域。

class Figure{enum Shape{RECTANGLE, CIRCLE};final Shape shape;double length;double width;double radius;Figure(double radius){shape = Shape.CIRCLE;this.radius = radius;}Figure(double length, double width){shape = Shape.RECTANGLE;this.length = length;this.width = width;}double area(){switch(shape){case RECTANGLE:return length * width;case CIRCLE:return Math.PI * (radius * radius);default:throw new AssertionError(shape);}}
}

标签类过于冗长、容易出错，并且效率低下

面向对象的语言（如 Java ）提供了其他更好的方法来定义能表示多种风格对象的单个数据类型：子类型化（ subtying）。标签类正是对类层次的一种简单的仿效。

标签类转为类层次：

首先要为标签类中的每个方法都定义一个包含抽象方法的抽象类，标签类的行为依赖于标签值。

在 Figure 类中，只有一个这样的方法： area 。这个抽象类是类层次的根（ root ）。如果还有其他的方法其行为不依赖于标签的值，就把这样的方法放在这个类中。

同样地，如果所有的方法都用到了某些数据域，就应该把它们放在这个类中。

在 Figure 类中，不存在这种类型独立的方法或者数据域。

接下来，为每种原始标签类都定义根类的具体子类。

在前面的例子中，这样的类型有两个：圆形（ circle ）和矩形（ rectangle ）。在每个子类中都包含特定于该类型的数据域。

在我们的示例中， radius 是特定于圆形的， length 和 width 是特定于矩形的。同时在每个子类中还包括针对根类中每个抽象方法的相应实现。

abstract class Figure{abstract double area();
}class Circle extends Figure{final double radius;Circle(double radius){this.radius = radius;}@Overridedouble area(){return Math.PI * (radius * radius);}
}
class Rectangle extands Figure{final double length;final double width;Rectangle(double length, double width){this.length = length;this.width = width;}@Overridedouble area(){return length * width;}
}

标签类很少有适用的时候。当你想要编写一个包含显式标签域的类时，应该考虑一下，这个标签是否可以取消，这个类是否可以用类层次来代替。当你遇到一个包含标签域的现有类时，就要考虑将它重构到一个层次结构中去。

24.静态成员类优于非静态成员类

嵌套类是指定义在另一个类的内部的类。存在的目的应该只是为它的外围类提供服务。如果嵌套类将来可能会用于其他的某个环境中，它就应该是顶层类（ top-level class ）。

嵌套类有四种：静态成员类、非静态成员类、匿名类和局部类。除了第一种之外，其他三种都称为内部类（ inner class ）。

静态成员类是最简单的一种嵌套类。最好把它看作是普通的类，只是碰巧被声明在另一个类的内部而己，它可以访问外围类的所有成员，包括那些声明为私有的成员。静态成员类是外围类的一个静态成员，与其他的静态成员一样，也遵守同样的可访问性规则。如果它被声明为私有的，它就只能在外围类的内部才可以被访问，等

非静态成员类的每个实例都隐含地与外围类的一个外围实例（巳nclosing instance ）相关联。在非静态成员类的实例方法内部，可以调用外围实例上的方法，或者利用修饰过的 this构造获得外围实例的引用

eg: set 和 list 这种集合接口的实现往往也使用非静态成员类来实现他们的迭代器

如果声明成员类不要求访问外围实例，就要始终把修饰符 static 放在它的声明中，

私有静态成员类的一种常见用法是代表外围类所代表的对象的组件

匿名类的运用受到诸多的限制。除了在它们被声明的时候之外，是无法将它们实例化的。

局部类是四种嵌套类中使用最少的类

25.限制源文件为单个顶级类

只要把顶级类（在本例中是指 Utensil 和 Dessert ）分别放入独立的源文件即可。如果一定要把多个顶级类放进一个源文件中，就要考虑使用静态成员类（详见第 24 条），以此代替将这两个类分到独立源文件中去。如果这些类服从于另一个类，那么将它们做成静态成员类通常比较好，因为这样增强了代码的可读性，如果将这些类声明为私有的（详见第 15 条），还可以使它们减少被读取的概率。