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

骑猪看日落 2022-08-28 07:44 209阅读 0赞

四、对于所有对象都通用的方法  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAemhlbmRlV0Q_size_20_color_FFFFFF_t_70_g_se_x_16]

#### 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

实现方法:

1.  认真研究接口，确定哪些方法是最基本的，其他方法则可以根据他们来实现，这些基本方法将成为骨架实现类中的抽象方法。
2.  在接口中为所有可以在基本方法之上直接实现的方法提供缺省方法，但不能为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 条），还可以使它们减少被读取的概率。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAemhlbmRlV0Q_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/4d096abca9d3486ab99b26128ea653f6.png