目录

默认方法

本章内容

  • 什么是默认方法
  • 如何以一种兼容的方式改进API
  • 默认方法的使用模式
  • 解析规则

传统上,Java程序的接口是将相关方法按照约定组合到一起的方式。实现接口的类必须为接 口中定义的每个方法提供一个实现,或者从父类中继承它的实现。但是,一旦类库的设计者需要 更新接口,向其中加入新的方法,这种方式就会出现问题。现实情况是,现存的实体类往往不在 接口设计者的控制范围之内,这些实体类为了适配新的接口约定也需要进行修改。由于Java 8的 API在现存的接口上引入了非常多的新方法,这种变化带来的问题也愈加严重,一个例子就是前 几章中使用过的List接口上的sort方法。想象一下其他备选集合框架的维护人员会多么抓狂吧, 像Guava和Apache Commons这样的框架现在都需要修改实现了 List 接口的所有类, 为其添加 sort方法的实现。

且慢,其实你不必惊慌。Java 8为了解决这一问题引入了一种新的机制。Java 8中的接口现在 支持在声明方法的同时提供实现,这听起来让人惊讶!通过两种方式可以完成这种操作。其一, Java 8允许在接口内声明静态方法。其二,Java 8引入了一个新功能,叫默认方法,通过默认方法 你可以指定接口方法的默认实现。换句话说,接口能提供方法的具体实现。因此,实现接口的类 如果不显式地提供该方法的具体实现,就会自动继承默认的实现。这种机制可以使你平滑地进行 接口的优化和演进。实际上,到目前为止你已经使用了多个默认方法。两个例子就是你前面已经 见过的List接口中的sort,以及Collection接口中的stream。

第1章中我们看到的List接口中的sort方法是Java 8中全新的方法,它的定义如下:

1
default void sort(Comparator<? super E> c){ Collections.sort(this, c); }

请注意返回类型之前的新default修饰符。通过它,我们能够知道一个方法是否为默认方法。 这里sort方法调用了Collections.sort方法进行排序操作。由于有了这个新的方法,我们现在可以直接通过调用sort,对列表中的元素进行排序。

https://gitee.com/lienhui68/picStore/raw/master/null/20200813103119.png

不过除此之外,这段代码中还有些其他的新东西。注意到了吗,我们调用了 Comparator.naturalOrder方法。这是Comparator接口的一个全新的静态方法,它返回一个 Comparator对象,并按自然序列对其中的元素进行排序(即标准的字母数字方式排序)。

第4章中你看到的Collection中的stream方法的定义如下:

1
default Stream<E> stream() { return StreamSupport.stream(spliterator(), false); }

我 们 在 之 前 的 几 章 中 大 量 使 用 了 该 方 法 来 处 理 集 合 , 这 里 stream 方 法 中 调 用 了 SteamSupport.stream 方法来返回一个流。 你注意到 stream 方法的主体是如何调用 spliterator方法的了吗?它也是Collection接口的一个默认方法。

1
2
3
4
@Override
    default Spliterator<E> spliterator() {
        return Spliterators.spliterator(this, 0);
    }

喔噢!这些接口现在看起来像抽象类了吧?是,也不是。它们有一些本质的区别,我们在这 一章中会针对性地进行讨论。但更重要的是,你为什么要在乎默认方法?默认方法的主要目标用户是类库的设计者啊。正如我们后面所解释的,默认方法的引入就是为了以兼容的方式解决像 Java API这样的类库的演进问题的,如图9-1所示。

https://gitee.com/lienhui68/picStore/raw/master/null/20200813103404.png

简而言之,向接口添加方法是诸多问题的罪恶之源;一旦接口发生变化,实现这些接口的类 往往也需要更新,提供新添方法的实现才能适配接口的变化。如果你对接口以及它所有相关的实 现有完全的控制,这可能不是个大问题。但是这种情况是极少的。这就是引入默认方法的目的: 它让类可以自动地继承接口的一个默认实现。

因此,如果你是个类库的设计者,这一章的内容对你而言会十分重要,因为默认方法为接口的演进提供了一种平滑的方式,你的改动将不会导致已有代码的修改。此外,正如我们后文 会介绍的,默认方法为类的多继承提供了一种更灵活的机制,可以帮助你更好地规划你的代码结构:类可以从多个接口继承默认方法。因此,即使你并非类库的设计者,也能在其中发现 感兴趣的东西。

静态方法及接口

同时定义接口以及工具辅助类(companion class)是Java语言常用的一种模式,工具类定义了与接口实例协作的很多静态方法。比如,Collections就是处理Collection对象的辅助类。java8之后由于静态方法可以存在于接口内部,你代码中的这些辅助类就没有了存在的必要,你可以把这些静态方法转移到接口内部。为了保持后向的兼容性,这些类依然会存在于Java应用程序的接口之中。

本章的结构如下。首先,我们会跟你一起剖析一个API演化的用例,探讨由此引发的各种 问题。 紧接着我们会解释什么是默认方法, 以及它们在这个用例中如何解决相应的问题。 之 后,我们会展示如何创建自己的默认方法,构造Java语言中的多继承。最后,我们会讨论一个 类在使用一个签名同时继承多个默认方法时,Java编译器是如何解决可能的二义性(模糊性) 问题的。

不断演进的API

更新已发布API会导致后向兼容性问题。这就是为什么对现存API的演进,比如官方 发布的Java Collection API,会给用户带来麻烦。当然,还有其他方式能够实现对API的改进,但 是都不是明智的选择。比如,你可以为你的API创建不同的发布版本,同时维护老版本和新版本, 但这是非常费时费力的,原因如下。其一,这增加了你作为类库的设计者维护类库的复杂度。其次,类库的用户不得不同时使用一套代码的两个版本,而这会增大内存的消耗,延长程序的载入 时间,因为这种方式下项目使用的类文件数量更多了。

这就是默认方法试图解决的问题。它让类库的设计者放心地改进应用程序接口,无需担忧对 遗留代码的影响,这是因为实现更新接口的类现在会自动继承一个默认的方法实现。

不同类型的兼容性:二进制、源代码和函数行为

变更对Java程序的影响大体可以分成三种类型的兼容性,分别是:二进制级的兼容、源代码级的兼容,以及函数行为的兼容。 刚才我们看到,向接口添加新方法是二进制级的兼容,但最终编译实现接口的类时却会发生编译错误。了解不同类型兼容性的特性是非常有益的,下面我们会深入介绍这部分的内容。

二进制级的兼容性表示现有的二进制执行文件能无缝持续链接(包括验证、准备和解析)和运行。比如,为接口添加一个方法就是二进制级的兼容,这种方式下,如果新添加的方法不被调用,接口已经实现的方法可以继续运行,不会出现错误。

源代码级的兼容性表示引入变化之后,现有的程序依然能成功编译通过。比如,向接口添加新的方法就不是源码级的兼容,因为遗留代码并没有实现新引入的方法,所以它们无法顺利通过编译。

函数行为的兼容性表示变更发生之后,程序接受同样的输入能得到同样的结果。比如,为接口添加新的方法就是函数行为兼容的,因为新添加的方法在程序中并未被调用(抑或该接口在实现中被覆盖了)。

概述默认方法

经过前述的介绍,我们已经了解了向已发布的API添加方法,对现存代码实现会造成多大的损害。默认方法是Java 8中引入的一个新特性,希望能借此以兼容的方式改进API。现在,接口包含的方法签名在它的实现类中也可以不提供实现。那么,谁来具体实现这些方法呢?实际上,缺失的方法实现会作为接口的一部分由实现类继承(所以命名为默认实现),而无需由实现类提供。

记住,函数式接口只包含一个抽象 方法,默认方法是种非抽象方法。

Java 8中的抽象类和抽象接口

那么抽象类和抽象接口之间的区别是什么呢?它们不都能包含抽象方法和包含方法体的实现吗?

首先,一个类只能继承一个抽象类,但是一个类可以实现多个接口。

其次,一个抽象类可以通过实例变量(字段)保存一个通用状态,而接口是不能有实例变量的。

默认方法的使用模式

这一节中,我 们会介绍使用默认方法的两种用例:可选方法和行为的多继承。

可选方法

你很可能也碰到过这种情况,类实现了接口,不过却刻意地将一些方法的实现留白。我们以 Iterator接口为例来说。Iterator接口定义了hasNext、next,还定义了remove方法。Java 8 之前,由于用户通常不会使用该方法,remove方法常被忽略。因此,实现Interator接口的类 通常会为remove方法放置一个空的实现,这些都是些毫无用处的模板代码。

采用默认方法之后,你可以为这种类型的方法提供一个默认的实现,这样实体类就无需在自 己的实现中显式地提供一个空方法。比如,在Java 8中,Iterator接口就为remove方法提供了 一个默认实现,如下所示:

1
2
3
4
5
interface Iterator<T> {
	boolean hasNext();
  T next();
  default void remove() { throw new UnsupportedOperationException(); }
}

通过这种方式,你可以减少无效的模板代码。实现Iterator接口的每一个类都不需要再声 明一个空的remove方法了,因为它现在已经有一个默认的实现。

行为的多继承

默认方法让之前无法想象的事儿以一种优雅的方式得以实现,即行为的多继承。这是一种让 类从多个来源重用代码的能力,如图9-3所示。

https://gitee.com/lienhui68/picStore/raw/master/null/20200813110018.png

Java的类只能继承单一的类,但是一个类可以实现多接口。要确认也很简单,下面是Java API 中对ArrayList类的定义:

https://gitee.com/lienhui68/picStore/raw/master/null/20200813110035.png

类型的多继承

这个例子中ArrayList继承了一个类,实现了六个接口。因此ArrayList实际是七个类型 的直接子类,分别是:AbstractList、List、RandomAccess、Cloneable、Serializable、 Iterable和Collection。所以,在某种程度上,我们早就有了类型的多继承。

由于Java 8中接口方法可以包含实现,类可以从多个接口中继承它们的行为(即实现的代码)。 让我们从一个例子入手,看看如何充分利用这种能力来为我们服务。保持接口的精致性和正交性能帮助你在现有的代码基上最大程度地实现代码复用和行为组合。

正交性

Orthogonality是表示“更改A不会更改B”的属性。正交系统的一个例子是无线电,在那里改变电台不会改变音量,反之亦然。

非正交系统就像直升机,改变速度可以改变方向。

在编程语言中,这意味着当您执行一条指令时,只会发生该指令,不会产生副作用(对于调试非常重要)。

利用正交方法的精简接口

假设你需要为你正在创建的游戏定义多个具有不同特质的形状。有的形状需要调整大小,但 是不需要有旋转的功能;有的需要能旋转和移动,但是不需要调整大小。这种情况下,你怎么设计才能尽可能地重用代码?

你可以定义一个单独的 Rotatable 接口, 并提供两个抽象方法 setRotationAngle 和 getRotationAngle,如下所示:

https://gitee.com/lienhui68/picStore/raw/master/null/20200813110829.png

这种方式和模板设计模式有些相似,都是以其他方法需要实现的方法定义好框架算法。 现在,实现了Rotatable的所有类都需要提供setRotationAngle和getRotationAngle 的实现,但与此同时它们也会天然地继承rotateBy的默认实现。

类似地,你可以定义之前看到的两个接口Moveable和Resizable。它们都包含了默认实现。 下面是Moveable的代码:

https://gitee.com/lienhui68/picStore/raw/master/null/20200813110934.png

组合接口

通过组合这些接口,你现在可以为你的游戏创建不同的实体类。比如,Monster可以移动、 旋转和缩放。

https://gitee.com/lienhui68/picStore/raw/master/null/20200813111119.png

Monster类会自动继承Rotatable、Moveable和Resizable接口的默认方法。这个例子中,Monster 继承了 rotateBy 、 moveHorizontally 、 moveVertically 和 setRelativeSize 的实现。 你现在可以直接调用不同的方法:

https://gitee.com/lienhui68/picStore/raw/master/null/20200813111206.png

假设你现在需要声明另一个类,它要能移动和旋转,但是不能缩放,比如说Sun。这时也无 需复制粘贴代码,你可以像下面这样复用Moveable和Rotatable接口的默认实现。图9-4是这一 场景的UML图表。

https://gitee.com/lienhui68/picStore/raw/master/null/20200813111239.png

像你的游戏代码那样使用默认实现来定义简单的接口还有另一个好处。 假设你需要修改 moveVertically的实现,让它更高效地运行。你可以在Moveable接口内直接修改它的实现, 所有实现该接口的类会自动继承新的代码(这里我们假设用户并未定义自己的方法实现)。

关于继承的一些错误观点

继承不应该成为你一谈到代码复用就试图倚靠的万精油。比如,从一个拥有100个方法及字段的类进行继承就不是个好主意,因为这其实会引入不必要的复杂性。你完全可以使用代理有效地规避这种窘境,即创建一个方法通过该类的成员变量直接调用该类的方法。这就是为什么有的时候我们发现有些类被刻意地声明为final类型:声明为final的类不能被其他的类继承,避免发生这样的反模式,防止核心代码的功能被污染。注意,有的时候声明为final的类都会有其不同的原因,比如,String类被声明为final,因为我们不希望有人对这样的核心功能产生干扰。

这种思想同样也适用于使用默认方法的接口。通过精简的接口,你能获得最有效的组合,因为你可以只选择你需要的实现。

解决冲突的规则

我们知道Java语言中一个类只能继承一个父类,但是一个类可以实现多个接口。随着默认方 法在Java 8中引入,有可能出现一个类继承了多个方法而它们使用的却是同样的函数签名。这种 情况下,类会选择使用哪一个函数?

在实际情况中,像这样的冲突可能极少发生,但是一旦发生 这样的状况,必须要有一套规则来确定按照什么样的约定处理这些冲突。这一节中,我们会介绍 Java编译器如何解决这种潜在的冲突。我们试图回答像“接下来的代码中,哪一个hello方法是 被C类调用的”这样的问题。注意,接下来的例子主要用于说明容易出问题的场景,并不表示这 些场景在实际开发过程中会经常发生。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
interface A {
    default void hello() {
        System.out.println("Hello from A");
    }
}

interface B extends A {
    default void hello() {
        System.out.println("Hello from B");
    }
}

class C implements A, B {

    public static void main(String[] args) {
        new C().hello();
    }
}

此外,你可能早就对C++语言中著名的菱形继承问题有所了解,菱形继承问题中一个类同时 继承了具有相同函数签名的两个方法。到底该选择哪一个实现呢? Java 8也提供了解决这个问题 的方案。请接着阅读下面的内容。

解决冲突的三条规则

如果一个类从多个地方(比如另一个类或接口)继承了使用相同函数签名的方法,通过三条规则可以进行判断。

  1. 类中的方法优先级最高。类或父类中声明的方法的优先级高于任何声明为默认方法的优 先级。
  2. 如果无法依据第一条进行判断,那么子接口的优先级更高:函数签名相同时,优先选择 拥有最具体实现的默认方法的接口,即如果B继承了A,那么B就比A更加具体。
  3. 最后,如果还是无法判断,继承了多个接口的类必须通过显式覆盖和调用期望的方法,显式地选择使用哪一个默认方法的实现。

选择提供了最具体实现的默认方法的接口

让我们回顾一下本节开头的例子,这个例子中C类同时实现了B接口和A接口,而这两个接口 恰巧又都定义了名为hello的默认方法。另外,B继承自A。图9-5是这个场景的UML图。

https://gitee.com/lienhui68/picStore/raw/master/null/20200813124250.png

编译器会使用声明的哪一个hello方法呢?按照规则(2),应该选择的是提供了最具体实现的 默认方法的接口。由于B比A更具体,所以应该选择B的hello方法。所以,程序会打印输出“Hello from B”。

现在,我们看看如果C像下面这样(如图9-6所示)继承自D,会发生什么情况:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
class C extends D implements A, B {

    public static void main(String[] args) {
        new C().hello();
    }
}

class D implements A {

}

https://gitee.com/lienhui68/picStore/raw/master/null/20200813124457.png

依据规则(1),类中声明的方法具有更高的优先级。D并未覆盖hello方法,可是它实现了接 口A。所以它就拥有了接口A的默认方法。规则(2)说如果类或者父类没有对应的方法,那么就应 该选择提供了最具体实现的接口中的方法。因此,编译器会在接口A和接口B的hello方法之间做 选择。由于B更加具体,所以程序会再次打印输出“Hello from B”。

我们在这个测验中继续复用之前的例子,唯一的不同在于D现在显式地覆盖了从A接口中继承的hello方法。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
class C extends D implements A, B {

    public static void main(String[] args) {
        new C().hello();
    }
}

class D implements A {
    @Override
    public void hello() {
        System.out.println("Hello from D");
    }
}

由于依据规则(1),父类中声明的方法具有更高的优先级,所以程序会打印输出“Hellofrom D”。

注意,D的声明如下:

1
2
3
abstract class D implements A {
    public abstract void hello();
}

这样的结果是,虽然在结构上,其他的地方已经声明了默认方法的实现,C还是必须提供自己的hello方法。

冲突及如何显示地消除歧义

到目前为止,你看到的这些例子都能够应用前两条判断规则解决。让我们更进一步,假设B 不再继承A(如图9-7所示):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
interface A {
    default void hello() {
        System.out.println("Hello from A");
    }
}

interface B {
    default void hello() {
        System.out.println("Hello from B");
    }
}

class C implements A, B {

    public static void main(String[] args) {
        new C().hello();
    }

}

https://gitee.com/lienhui68/picStore/raw/master/null/20200813124905.png

这时规则(2)就无法进行判断了,因为从编译器的角度看没有哪一个接口的实现更加具体,两 个都差不多。A接口和B接口的hello方法都是有效的选项。所以,Java编译器这时就会抛出一个 编译错误,因为它无法判断哪一个方法更合适:“Error: class C inherits unrelated defaults for hello() from types B and A.”

冲突的解决

解决这种两个可能的有效方法之间的冲突,没有太多方案;你只能显式地决定你希望在C中 使用哪一个方法。为了达到这个目的,你可以覆盖类C中的hello方法,在它的方法体内显式地 调用你希望调用的方法。Java 8中引入了一种新的语法X.super.m(…),其中X是你希望调用的m 方法所在的父接口。举例来说,如果你希望C使用来自于B的默认方法,它的调用方式看起来就如 下所示:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
class C implements A, B {

    public static void main(String[] args) {
        new C().hello();
    }

    @Override
    public void hello() {
        B.super.hello();
    }
}

菱形继承问题

让我们考虑最后一种场景,它亦是C++里中最令人头痛的难题。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
interface A {
    default void hello() {
        System.out.println("Hello from A");
    }
}

interface B extends A {
}

interface C extends A {
}

class D implements B, C {
    public static void main(String[] args) {
        new D().hello();
    }
}

图9-8以UML图的方式描述了出现这种问题的场景。这种问题叫“菱形问题”,因为类的继承 关系图形状像菱形。这种情况下类D中的默认方法到底继承自什么地方 ——源自B的默认方法, 还是源自C的默认方法?实际上只有一个方法声明可以选择。只有A声明了一个默认方法。由于这 个接口是D的父接口,代码会打印输出“Hello from A”。

https://gitee.com/lienhui68/picStore/raw/master/null/20200813125329.png

现在,我们看看另一种情况,如果B中也提供了一个默认的hello方法,并且函数签名跟A 中的方法也完全一致,这时会发生什么情况呢?根据规则(2),编译器会选择提供了更具体实现的 接口中的方法。由于B比A更加具体,所以编译器会选择B中声明的默认方法。如果B和C都使用相 同的函数签名声明了hello方法,就会出现冲突,正如我们之前所介绍的,你需要显式地指定使 用哪个方法。

顺便提一句,如果你在C接口中添加一个抽象的hello方法(这次添加的不是一个默认方法), 会发生什么情况呢?你可能也想知道答案。

1
public interface C extends A { void hello(); }

因为C接口更加具体。因此,类D现在需要为hello显式地添加实现,否则该程序无法通过编译。新添加到C接口中的抽象方法hello比由接口A继承而来的hello方法拥有更高的优先级,

C++语言中的菱形问题

C++语言中的菱形问题要复杂得多。首先,C++允许类的多继承。默认情况下,如果类D继承了类B和类C,而类B和类C又都继承自类A,类D实际直接访问的是B对象和C对象的副本。最后的结果是,要使用A中的方法必须显式地声明:这些方法来自于B接口,还是来自于C接口。此外,类也有状态,所以修改B的成员变量不会在C对象的副本中反映出来。

现在你应该已经了解了,如果一个类的默认方法使用相同的函数签名继承自多个接口,解决 冲突的机制其实相当简单。你只需要遵守下面这三条准则就能解决所有可能的冲突。

  • 首先,类或父类中显式声明的方法,其优先级高于所有的默认方法。
  • 如果用第一条无法判断,方法签名又没有区别,那么选择提供最具体实现的默认方法的 接口。
  • 最后,如果冲突依旧无法解决,你就只能在你的类中覆盖该默认方法,显式地指定在你 的类中使用哪一个接口中的方法。

小结

下面是本章你应该掌握的关键概念。

  • Java 8中的接口可以通过默认方法和静态方法提供方法的代码实现。
  • 默认方法的开头以关键字default修饰,方法体与常规的类方法相同。
  • 向发布的接口添加抽象方法不是源码兼容的。
  • 默认方法的出现能帮助库的设计者以后向兼容的方式演进API。
  • 默认方法可以用于创建可选方法和行为的多继承。
  • 我们有办法解决由于一个类从多个接口中继承了拥有相同函数签名的方法而导致的冲突。
  • 类或者父类中声明的方法的优先级高于任何默认方法。如果前一条无法解决冲突,那就选择同函数签名的方法中实现得最具体的那个接口的方法。
  • 两个默认方法都同样具体时,你需要在类中覆盖该方法,显式地选择使用哪个接口中提供的默认方法。