Effective Java（三）

三、类和接口

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

        要区别设计良好的模块与设计不好的模块，最重要的因素在于：这个模块对于外界的其他模块而言，是否隐藏其内部数据和其他实现细节。一个模块不需要知道其他模块的内部工作情况，这个概念被称为信息隐藏或封装，是软件设计的基本原则之一。

        访问控制（类、接口和成员的可访问性）的第一原则：尽可能地使每个类或者成员不被外界访问，即应使用与你正在编写的软件对应功能相一致的，尽可能最小的访问级别。

        公有的静态final域要么包含基本的类型的值，要么包含指向不可变对象的引用。如果final域包含可变对象的引用，它变具有非final域的所有缺点。虽然引用本身不能被修改，但是它所被引用的对象却可以被修改，这会导致灾难性的后果。

        一种常见的错误：类具有公有的静态final数据域，或者返回这种域的访问方法，这几乎总是错误的。原因是：长度非零的数组总是可变的。

//OBJECTS是不可变的，但它所指的对象却是可变的，这点特别容易被忽视，造成安全漏洞
public static final Thing[] VALUES = {...};

//修改办法一
private static final Thing[] PRIVATE_VALUES = {...};
public static final List<Thing> VALUES = Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

//修改办法二
private static final Thing[] PRIVATE_VALUES = {...};
public static final Thing[] values() {
    return PRIVATE_VALUES.clone();

        除了公有静态final域的特殊情形之外，公有类都不应该包含公有域。并且要确保公有静态final域所引用的对象都是不可变的。

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

        公有类永远不应该暴露可变的域。

        在公有类中，将数据域设置成私有域，然后使用公有的访问方法（getter）和公有的设值方法（setter）去访问。

3. 使可变性最小化

        不可变类指的是实例不能被修改的类。每个实例中包含的所有信息都必须在创建该实例的时候就提供，并在对象的整个生命周期内固定不变。Java平台类库中包含许多不可变的类，有String、BigInteger、BigDecimal、基本类型包装类。

        存在不可变类的理由：不可变的类比可变类更加易于设计、实现和使用，它们不易出错，且更加安全。

为了使类不可变，要遵循下面5条原则：

（1）不要提供任何会修改对象状态的方法

（2）保证类不会被扩展

（3）使所有的域都是final的

（4）使所有的域都成为私有的

（5）确保对于任何可变组件的互斥访问

不可变类的优点：

• 不可变对象比较简单
• 不可变对象本质上是线程安全的，它们不要求同步
• 不可变对象可以被自由地共享，不需要进行保护性拷贝
• 不可变对象为其他对象提供了大量的构件

不可变类的缺点：

• 对于每个不同的值都需要一个单独的对象。在特定情况下存在潜在的性能问题。当把较大的值对象做成不可变类时，若其会对性能造成影响，可以为它提供相应的可变配套类。

        创建这种对象的代价可能很高，特别是对于大型对象的情形。对于大型的对象，最好的办法是提供一个公有的可变配套类，如String的公有配套类StringBuilder。

        为了确保不可变性，类绝对不允许自身被子类化。除了“使类成为final的”这种方法外，还可以让类的所有构造器都变成私有的或者包级私有的，并添加公有的静态工厂来代替公有的构造器。

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

4. 复合优先于继承

        对普通的具体类进行跨越包边界的继承，是非常危险的。

• 继承打破了封装性。子类依赖于超类中特定功能的实现细节。超类的实现有可能会随着发行版本的不同而有所变化，如果真的发生了变化，子类可能会遭到破坏。因此，子类必须要跟着超类的更新而演变，除非超类是专门为了扩展而设计的，且具有很好的文档说明。
• 另一个危险的原因来源于覆盖（overriding）动作。如果在扩展一个类的时候，仅仅是添加新的方法，而不覆盖现有的方法，你可能会认为这是安全的。但是，如果超类在后续的发行版本中获得了一个新的方法，并且不幸的是，你给子类提供了一个签名相同但返回类型不同的方法，这样的子类将无法通过编译。

        注意：只有当子类真正是超类的子类型时，才适合继承。换言之，对于两个类A和B，只有当两者之间确实存在“is-a”关系的时候，类B才应该扩展类A。

        采用复合则可以避免上述问题。复合是不用扩展现有的类，而是在新的类中增加一个私有域，它引用现有类的一个实例。新类中的每个实例方法都可以调用被包含的现有类实例中对应的方法，并返回它的结果。这被称为转发。新类中的方法被称为转发方法。这样得到的类非常稳固，它不依赖于现有类的实现细节。即使现有的类添加了新的方法，也不影响新的类。

5. 要么就为继承而设计，并提供文档说明，要么就禁止继承

        对不是为了继承而设计、并且没有文档说明的“外来”类进行子类化是很危险的。
        对于为了继承而设计的类，该类的文档必须要精确地描述覆盖每个方法所带来的影响。即该类必须有文档说明它可覆盖的方法的自用性。对于每个公有的或受保护的方法或构造器，它的文档必须指明该方法或构造器调用了哪些可覆盖的方法，是以什么顺序调用的，每个调用的结果又是如何影响后续的处理过程的。

        为了允许继承，类还必须遵守其他一些约束：构造器决不能调用可被覆盖的方法，无论是直接调用还是间接调用。如果违反了这条规则，很有可能导致程序失败。

        对于普通的具体类，它们既不是final的，也不是为了子类化而设计和编写文档的，继承它们是非常危险的，因为每次对这种类进行修改，从这个类扩展得到的客户类都有可能遭到破坏。对这个问题的最佳解决方案是：对于那些并非为了安全地进行子类化而设计和编写文档的类，要禁止子类化。

有两种方法可以禁止子类化：

（1）把这个类声明为final的

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

        如果禁止继承可能会带来不便，或者认为必须允许从这样的类继承，一种合理的办法是确保这个类永远不会调用它的任何可覆盖的方法，并在文档中说明这一点。换言之，完全消除这个类中可覆盖方法的自用特性。这样做之后，就可以创建“能够安全地进行子类化”的类。覆盖方法将永远也不会影响其他任何方法的行为。

        你可以消除类中可覆盖方法的自用特性，而不改变它的行为。将每个可覆盖方法的代码体移到一个私有的“辅助方法”中，并且让每个可覆盖的方法调用它的私有辅助方法，然后直接调用私有的辅助方法来代替可覆盖方法，去除可覆盖方法的自用调用。

总结：

• 为继承而设计的类，要提供文档说明，并在发布前编写子类进行测试；
• 对于普通的类，要尽可能地禁止其子类化，可以将其声明为final或使用静态方法来代替构造器；
• 对于无法禁止子类化的类，要消除这种类中可被子类覆盖的方法的自用性，即在父类中使用的方法，要确保其在子类中不可被覆盖。

6. 接口优先于抽象类

使用接口定义类型的好处：

• 现有的类可以很容易被更新，以实现新的接口类型
• 接口是定义mixin（混合类型）的理想选择
• 接口允许我们构造非层次结构的类型框架

        接口和抽象类两者最明显的区别是抽象类允许包含某种方法的实现，但是接口则不允许。 

        虽然接口不允许包含方法的实现，但是，使用接口来定义类型并不妨碍它对于实现上带来的帮助。通过对每个重要的接口都提供一个骨架实现类，把接口和抽象类的优点结合起来。

        骨架实现类与普通的实现上有个明显的不同就是它会包含一些简单实现。虽然它实现了接口，并且是为了继承而设计的。但是其中的简单实现不是抽象的，而是最简单的可能的有效实现。你可以原封不动的使用，也可以看情况将它子类化。

        下图是Java容器框架图，其中就利用了接口和骨架实现类。

        

       

public abstract class AbstractMapEntry<K, V> implements Map.Entry<K, V> {
    public abstract K getKay();
    public abstract V getValue();
    
    public V setValue(V value) {
        throw new UnsupportedOperationException();
    }


    @Override
    public int hashCode() {
        return hashCode(getKay()) ^ hashCode(getValue());
    }
    
    @Override
    public boolean equals(Object obj) {
        if (obj == null) {
            return true;
        }
        if (!(obj instanceof Map.Entry)) {
            return false;
        }
        Map.Entry<?, ?> arg = (Map.Entry)obj;
        return equals(getKey(), arg.getKey()) && equals(getValue(), arg.getValue());
    }
    
    private static boolean equals(Object o1, Object o2) {
        return o1 == null ? o2 == null : o1.equals(o2);
    }
    
    private static int hashCode(Object obj) {
        return obj == null ? 0 : obj.hashCode();
    }
}

        设计公有接口要非常谨慎。接口一旦被公开发行，并且被广泛实现，再想改变这个接口几乎是不可能的。一般来说，要想在公有接口中增加方法，并不破坏实现这个接口的所有现有的类，这是不可能的。之前实现该接口的类都将漏掉新增加的方法，并且无法再通过编译。

7. 接口只用于定义类型

        当类实现接口时，接口就充当了可以引用这个类的实例的类型。类实现了接口，就表明客户端可以让这个类的实例执行接口定义的动作。为了任何其他的目的而定义接口是不恰当的。
        常量接口模式是对接口的不良使用：

public interface PhysicalConstants {
    static final double AVOGANDROS_NUMBER = 6.02214199e23;
    static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
    static final double ELECTRON_MASS = 9.10938188e-31;
}

        类在内部使用某些常量，纯粹是实现细节。实现常量接口，会导致把这样的实现细节泄露到该类的导出API中。更糟糕的是它代表了一种承诺，如果将来的版本中这个类被修改了，不再需要使用这些常量了，它仍必须实现这个接口，以确保二进制兼容性。如果非final类实现了常量接口，它的所有子类的命名空间也会被接口中的常量所“污染”。  

导出常量，通常有三种处理方法：

• 如果常量与某个现有类或者接口紧密相关，就应该把常量添加到这个类或接口中
• 如果常量被看作枚举类型的成员，就应该使用枚举类型
• 将常量定义在不可实例化的工具类中

        工具类通常需要客户端要用类名来修饰这些常量名，如果大量利用工具类导出的常量，可以通过静态导入机制（Java 1.5 后引入），避免用类名来修饰常量名。

// Use of static import to avoid qualifying constants
import static com.effectivejava.science.PhysicalConstants.*;

public class Test {
    double atoms(double mols) {
        return AVOGADROS_NUMBER = mols;
    }
    ...
    // Many more uses of PhysicalConstants justify static import
}

8. 类层次优于标签类

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

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();
        }
    }
}

        这种标签类有许多缺点。它充斥着样板代码，将多个实现挤在单个类中，可读性很差；内存占用增加；如果要添加风格，必须得给每个条件语句添加一个条件；实例的数据类型没有提供任何关于其风格的线索。简而言之，标签类过于冗长、容易出错、效率低下。

        Java可以采用子类型化来构建类层次，以此替换标签类。

将标签类转变成类层次，具体做法如下：

• 定义一个抽象类，将标签类中依赖标签值的方法定义在抽象类中
• 为每种原始标签类都定义根类的具体子类

abstract class Figure {
    abstract double area();
}

class Circle extends Figure {
    final double radius;

    Circle(double radius) {
        this.radius = radius;
    }

    double area() {
        return Math.PI * (radius * radius);
    }
}

class Rectangle extends Figure {
    final double length;
    final double width;

    Rectangle(double length, double width) {
        this.length = length;
        this.width = width;
    }

    double area() {
        return length * width;
    }
}

        类层次结构避免了标签类所有的缺点，更重要的是它反映了类型之间本质上的层次关系，有助于增强灵活性，并可提供编译时检查，且非常容易扩展。 

9. 用函数对象表示策略

        有些语言支持函数指针、代理、lambda表达式，或者支持类似的机制，允许程序把“调用特殊函数的能力”存储起来并传递这种能力。这种机制通常用于允许函数的调用者通过传入第二个函数，来指定自己的行为。

        Java没有提供函数指针，但可以用对象引用实现同样的功能。可以定义这样一种对象：它的方法执行其他对象（这些对象被显式传递给这些方法）上的操作。如果一个类仅仅导出一个这样的方法，它的实例实际上就等同于一个指向该方法的指针。这样的实例被称为函数对象。

/*
* StringLengthComparator导出一个带两个字符串参数的方法
*指向它对象的引用可以被当作是一个指向该比较器的函数指针，它可以在任意一对字符串上调用
*/
class StringLengthComparator {
    public int compare(String s1, String s2) {
        return s1.length() - s2.length();
    }
}

        上述方法是一个比较器，它根据长度给字符串排序。指向StringLengthComparator对象的引用可以被当作是一个指向该比较器的“函数指针”，可以在任意一个字符串上被调用。换句话说，StringLengthComparator实例是用于字符串比较操作的具体策略。 作为典型的具体策略类，StringLengthComparator是无状态的，它没有域，所以这个类的所有实例在功能上都是相互等价的。因此，它作为一个Singleton是非常合适的，可以节省不必要的对象创建开销：

class StringLengthComparator {
    private StringLengthComparator() {}

    public static final StringLengthComparator INSTANCE = new StringLengthComparator();

    public int compare(String s1, String s2) {
        return s1.length() - s2.length();
    }
}

        为了把StringLengthComparator实例传递给方法，需要适当的参数类型。使用StringLengthComparator并不好，因为客户端将无法传递任何其他的比较策略。因此，在设计具体的策略类时，需要定义一个策略接口：

public interface Comparator<T> {
    public int compare(T t1, T t2);
}

        具体的策略类往往使用匿名类声明： 

Arrays.sort(stringArray, new Comparator<String>() {
    public int compare(String s1, String s2) {
        return s1.length() - s2.length();
    }
});

        使用匿名类时，将会在每次执行调用时创建一个新的实例。如果它被重复执行，可以考虑将一个函数对象存储到一个私有的静态final域里，并重用它。这样做另外一个好处是：可以为这个函数对象取一个有意义的域名称。

//通过公有静态final域导出具体实现策略
class Host {
    private static class StrLenCmp implements Comparator<String> {
        public int compare(String s1, String s2) {
            return s1.length() - s2.length();
        }
    }

    public static final Comparator<String> STRING_LENGTH_COMPARATOR = new StrLenCmp();
}

10. 优先考虑静态成员类

        嵌套类是指被定义在另一个类的内部的类。嵌套类存在的目的应该只是为它的外围类提供服务。如果嵌套类将来可能会用于其它的某个环境中，它就应该被设计为顶层类。
        嵌套类有四种：静态成员类、非静态成员类、匿名类、局部类。

        静态成员类是最简单的一种嵌套类。它可以访问外部类的所有成员，包括那些声明为私有的成员。静态成员类是外围类的一个静态成员，与其他的静态成员一样，也遵守同样的可访问性规则。如果它被声明为私有的，它就只能在外围类的内部才可以被访问。静态成员类的一种常见用法是作为公有的辅助类，仅当与它的外部类一起使用时才有意义。

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

        非静态成员类的一个常见用法是定义一个Adapter，它允许外部类的实例被看作是另一个不相关的类的实例。同样地，诸如Set和List这种集合接口的实现往往也使用非静态成员类来实现它们的迭代器（iterator）：

//非静态成员类实现了Set的集合视图
public class MySet<E> extends AbstractSet<E> {
    ...

    public Iterator<E> iterator() {
        return new MyIterator();
    }

    private class MyIterator implements Iterator<E> {
        ...
    }
}

        匿名类没有名字，它在使用的同时被声明和实例化，由于匿名类出现在表达式中，它们必须保持简短（大约10行或者更少些），否则就会影响程序的可读性。

匿名类的常见用法：

• 动态地创建函数对象，如匿名的Comparator实例
• 创建过程对象，如Runnable、Thread、TimeTask实例
• 用在静态工厂方法的内部

        局部类是四种嵌套类中用的最少的类，在任何“可以声明局部变量”的地方都可以声明局部类，并且局部类也遵守同样的作用域规则。它有名字，可被重复地使用，它不能包含静态成员，必须非常简短，以免影响可读性。        

        四种嵌套类都有自己的用途。如果一个嵌套类需要在单个方法之外仍然可见，或者它太长了，不适合放在方法内部，就应该使用成员类。如果成员类的每个实例都需要一个指向其外围实例的引用，就要把成员类声明为非static的；否则就声明为static的。如果这个嵌套类属于一个方法的内部，而你只需要在一个地方创建实例，并且已经有了一个预置的类型可以说明这个类的特征，就要把它做成匿名类；否则，就做成局部类。