四、对于所有对象都通用的方法
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;}
@Override
double 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;
}
@Override
double area(){
return length * width;
}
}
标签类很少有适用的时候 。 当你想要编写一个包含显式标签域的类时，应该考虑一下，这个标签是否可以取消，这个类是否可以用类层次来代替 。 当你遇到一个包含标签域的现有类时，就要考虑将它重构到一个层次结构中去 。
24.静态成员类优于非静态成员类
嵌套类是指定义在另 一个类的内部的类 。 存在的目的应该只是为它的外围类提供服务 。 如果嵌套类将来可能会用于其他的某个环境中，它就应该是顶层类（ top-level class ） 。
嵌套类有 四种： 静态成员类、非静态成员类、匿名类和局部类 。 除了第一种之外，其他三种都称为内部类（ inner class ） 。
静态成员类是最简单的一种嵌套类 。 最好把它看作是普通的类，只是碰巧被声明在另一个类的内部而己，它可以访问外围类的所有成员，包括那些声明为私有的成员 。 静态成员类是外围类的一个静态成员，与其他的静态成员一样，也遵守同样的可访问性规则 。 如果它被声明为私有的，它就只能在外围类的内部才可以被访问，等
非静态成员类的每个实例都隐含地与外围类的一个外围实例 （巳nclosing instance ）相关联 。 在非静态成员类的实例方法内部，可以调用外围实例上的方法，或者利用修饰过的 this构造获得外围实例的引用
eg: set 和 list 这种集合接口的实现往往也使用非静态成员类来实现他们的迭代器
如果声明成员类不要求访问外围实例，就要始终把修饰符 static 放在它的声明中，
私有静态成员类的一种常见用法是代表外围类所代表的对象的组件
匿名类的运用受到诸多的限制 。 除了在它们被声明的时候之外，是无法将它们实例化的 。
局部类是四种嵌套类中使用最少的类
25.限制源文件为单个顶级类
只要把顶级类（在本例中是指 Utensil 和 Dessert ）分别放入独立的源文件即可 。 如果一定要把多个顶级类放进一个源文件中，就要考虑使用静态成员类（详见第 24 条），以此代替将这两个类分到独立源文件中去 。 如果这些类服从于另一个类，那么将它们做成静态成员类通常比较好，因为这样增强了代码的可读性，如果将这些类声明为私有的（详见第 15 条），还可以使它们减少被读取的概率。
238
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
