第20项：接口优先于抽象类

  Java程序设计语言提供了两种机制，可以用来定义允许多个实现的类型：接口和抽象类。自从Java 8[JLS 9.4.3]中引入接口的默认方法依赖，这两种机制都允许您为某些实例方法提供实现。一个更为重要的区别在于，为了实现由抽象类定义的类型，类必须称为抽象类的一个子类。任何一个类，只要它定义了所有必要的方法，并且遵守通用约定，它就被允许实现一个接口，而不管这个类是处于类层次（class hierarchy）的哪个位置。因为Java只允许单继承，所以，抽象类作为类型定义受到了极大的限制。

  现有的类可以很容易被更新，以实现新的接口。 如果这些方法尚不存在，你所需要做的就只是增加必要的方法，然后在类的声明中增加一个implements子句。例如，许多现有类被改进引入Java平台上时实现Comparable、Iterable和Autocloseable接口。通常，现有的类不能被改进以扩展新的抽象类。如果你希望让两个类扩展同一个抽象类，就必须把抽象类放到类型层次（type hierarchy）的高处，以便这两个类的一个祖先成为它的子类。遗憾的是，这样做会间接地对类的层次结构造成破坏，迫使这个公共祖先的所有后代类都扩展这个新的抽象类，无论它对于这些后代类是否合适。

  接口是定义混合类型（mixin）的理想选择。 不严格地讲，mixin是指这样的类型：类除了实现它的“基本类型（primary type）”之外，还可以实现这个mixin类型，以表明它提供了某些可供选择的行为。例如，Comparable就是一个mixin接口，它允许类表明它的实例可以与其他的可相互比较的对象进行排序。这样的接口之所以被称为mixin，是因为它允许任选的功能可被混合到类型的主要功能中。抽象类不能被用于定义mixin，同样也是因为它们不能被更新到现有的类中，类不可能有一个以上的父类，类层次结构中也没有适当的地方来插入mixin。

  接口允许我们构造非层次结构的类型框架。 类型层次对于组织某些事物是非常合适的，但是其他有些事物并不能被整齐地组织成一个严格的层次结构。例如，假设我们有一个接口代表一个singer（歌唱家），另一个接口代表一个songwriter（作曲家）：

public interface Singer {
    AudioClip sing(Song s);
}

public interface Songwriter {
    Song compose(int chartPosition);
}

  在现实生活中，有些歌唱家本身也是作曲家。因为我们使用了接口而不是抽象类来定义这些类型，所以对于单个类而言，它同时实现Singer和Songwriter是完全允许的。实际上，我们可以定义第三个接口，它同时扩展了Singer和Songwriter，并添加了一些适合于这种组合的新方法：

public interface SingerSongwriter extends Singer, Songwriter {
    AudioClip strum();
    void actSensitive();
}

  你并不总是需要这中灵活性，但是一旦你这样做了，接口可就成了救世主。另一种做法是编写一个臃肿（bloated）的类层次，对于每一种要被支持的属性组合，都包含一个单独的类。如果在整个类型系统中有n个属性，那么就必须支持2^n种可能的组合。这种现象被称为“组合爆炸（combinatorial explosion）”。类层次臃肿会导致类也臃肿，这些类包含许多方法，并且这些方法只是在参数的类型上有所不同而已，因为类层次中没有任何类型体现了公共的行为特征。

  通过第18项中介绍的包装类（wrapper class）模式，接口使得安全地增强类的功能称为可能。如果使用抽象类来定义类型，那么程序猿除了使用继承的手段来增加功能，没有其他的选择。这样得到的类与包装类相比，功能更差，也更加脆弱。

  当根据其他接口方法显示实现接口方法时，请考虑以默认方法的形式向程序猿提供实现帮助。例如使用这种方式的一个例子，看【原书】第104页的removeIf方法。如果你提供了默认的方法，请务必使用Javadoc的标记@implSpec来为它们的继承提供文档。

  使用默认方法提供的帮助是有限的。尽管许多接口都指定了Object方法（如equals和hashCode）的行为，但是不允许为它们提供默认方法。此外，不允许接口包含实例字段或非公共静态成员（私有静态方法除外）。最后，你无法将默认方法添加到您无法控制的接口。

  但是，你可以通过提供与接口一起使用的抽象骨架实现（skeletal implementation）类来结合接口和抽象类的优点。接口定义类型，可能提供一些默认方法，而骨架实现类在基本接口方法上实现剩余的非基本接口方法。扩展骨架实现需要完成大部分工作来实现接口。这是模板方法模式[Gamma95]。

  按照惯例，骨架实现被称为AbstractInterface，这里的Interface是指所实现的接口的名字。例如，Collections Framework为每个重要的集合接口都提供了一个骨架实现，包括AbstraceCollection、AbstractSet、AbstractList和AbstractMap。将它们称作SkeletalCollection、SkeletalSet、SkeletalList和SkeletalMap也是有道理的，但是现在Abstract的用法已经根深蒂固。如果设计得当，骨架实现（无论是否是单独的抽象类，或者仅包含接口上的默认方法）可以使程序猿很容易提供他们自己的接口实现。例如，这是一个静态工厂方法，基于AbstractList的包含一个完整的，功能齐全的List实现：

// Concrete implementation built atop skeletal implementation
static List<Integer> intArrayAsList(int[] a) {
    Objects.requireNonNull(a);
    // The diamond operator is only legal here in Java 9 and later
    // If you're using an earlier release, specify <Integer>
    return new AbstractList<>() {
        @Override public Integer get(int i) {
            return a[i]; // Autoboxing (Item 6)
        }

        @Override public Integer set(int i, Integer val) {
            int oldVal = a[i];
            a[i] = val; // Auto-unboxing
            return oldVal; // Autoboxing
        }

        @Override public int size() {
            return a.length;
        }
    };
}

  当你考虑一个List实现应该为你完成哪些工作的时候，可以看出，这个例子充分演示了骨架实现的强大功能。顺便提一下，这个例子是个Adapter[Gamma95, p.139]，它允许将int数组看做Integer实例的列表。由于在int值和Integer实例之间来回转换需要开销（装箱和开箱），它的性能不会很好。注意，这个例子中只提供一个静态工厂，并且这个类还是个不可被访问的匿名类（anonymous class）（第24项），它被隐藏在静态工厂的内部。

  骨架实现的美妙之处在于，他们为抽象类提供了实现上的帮助，但又不强加“抽象类被用作类型定义时”所特有的严格限制。对于接口的大多数实现来讲，扩展骨架实现类是个很显然的选择，但并不是必须的。如果预置的类无法扩展骨架实现类，则该类始终可以直接实现该接口。该类仍然受益于接口本身存在的任何默认方法。此外，骨架实现类仍然能够有助于接口的实现。实现了这个接口的类可以把对于这个接口方法的调用，转发到一个内部私有类的实例上，这个内部私有类扩展了骨架实现类。这种方法被称作模拟多重继承（simulated multiple inheritance），它与第18项中讨论的包装类模式密切相关。这项技术具有剁成继承的绝大多数有点，同时又避免了相应的缺陷。

  编写骨架实现类的过程相对比较简单，只是有点单调乏味。首先，必须认真研究接口，并确定哪些方法是最为基本的（primitive），其他的方法则可以根据它们来实现。这些基本方法将成为骨架实现类中的抽象方法。然后，必须在接口中为可以直接在基本方法上实现的所有方法提供默认方法，但请记住，你可能不会为Object方法（如equals和hashCode）提供默认方法。如果基本方法和默认方法覆盖了接口，那么你就完成了，并且不需要骨架实现类。否则，编写一个声明为实现接口的类，并使用所有剩余接口方法的实现。该类可以包含适合该任务的任何非公共字段和方法（The class may contain any nonpublic fields ands methods appropriate to the task.）。

  举个简单的例子，考虑一下Map.Entry接口。明显的基本方法是getKey，getValue和（可选）setValue。接口指定了equals和hashCode的行为，并且在基本方法里有一个明显的toString实现。由于不允许你为Object方法提供默认实现，因此所有实现都放在骨架实现类中：

// Skeletal implementation class
public abstract class AbstractMapEntry<K,V> implements Map.Entry<K,V> {
    // Entries in a modifiable map must override this method
    @Override public V setValue(V value) {
        throw new UnsupportedOperationException();
    }

    // Implements the general contract of Map.Entry.equals
    @Override public boolean equals(Object o) {
        if (o == this)
            return true;
        if (!(o instanceof Map.Entry))
            return false;
        Map.Entry<?,?> e = (Map.Entry) o;
            return Objects.equals(e.getKey(), getKey()) && Objects.equals(e.getValue(), getValue());
    }

    // Implements the general contract of Map.Entry.hashCode
    @Override public int hashCode() {
        return Objects.hashCode(getKey()) ^ Objects.hashCode(getValue());
    }

    @Override public String toString() {
        return getKey() + "=" + getValue();
    }
}

  请注意，此骨架实现无法在Map.Entry接口中实现或作为子接口实现，因为不允许使用默认方法重写Object方法，如equals，hashCode和toString。

  因为骨架实现是为继承而设计的，所以您应该遵循第19项中的所有设计和文档指南。为简洁起见，前面的示例中省略了文档注释，但是良好的文档在骨架实现中是绝对必要的， 无论它是否包含接口的默认方法或单独的抽象类。

  骨架实现上有个小小的不同，就是简单实现（simple implementation），例如AbstractMap.SimpleEntry。一个简单的实现就像一个骨架实现，因为它实现了一个接口并且是为继承而设计的，但它的不同之处在于它不是抽象的：它是最简单的可行工作实现（it is the simplest possible working implementation.）。您可以根据情况使用它，也可以根据情况保留子类。

  总而言之，接口通常是定义允许多个实现的类型的最佳方式。如果你要暴露一个重要的接口，你应该强烈考虑提供一个骨架实现来配合它。在可能的范围内，你应该通过接口上的默认方法提供骨架实现，以便接口的所有实现者都可以使用它。也就是说，对接口的限制通常要求骨架实现采用抽象类的形式。

第21项：为“后代”设计接口（design interface for posterity）