Effective Java 第三版——21. 为后代设计接口

Tips
《Effective Java, Third Edition》一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将近8年的时间,但随着Java 6,7,8,甚至9的发布,Java语言发生了深刻的变化。
在这里第一时间翻译成中文版。供大家学习分享之用。

21. 为后代设计接口

在Java 8之前,不可能在不破坏现有实现的情况下为接口添加方法。 如果向接口添加了一个新方法,现有的实现通常会缺少该方法,从而导致编译时错误。 在Java 8中,添加了默认方法( default method)构造[JLS 9.4],目的是允许将方法添加到现有的接口。 但是增加新的方法到现有的接口是充满风险的。

默认方法的声明包含一个默认实现,该方法允许实现接口的类直接使用,而不必实现默认方法。 虽然在Java中添加默认方法可以将方法添加到现有接口,但不能保证这些方法可以在所有已有的实现中使用。 默认的方法被“注入(injected)”到现有的实现中,没有经过实现类的知道或同意。 在Java 8之前,这些实现是用默认的接口编写的,它们的接口永远不会获得任何新的方法。

许多新的默认方法被添加到Java 8的核心集合接口中,主要是为了方便使用lambda表达式(第6章)。 Java类库的默认方法是高质量的通用实现,在大多数情况下,它们工作正常。 但是,编写一个默认方法并不总是可能的,它保留了每个可能的实现的所有不变量

例如,考虑在Java 8中添加到Collection接口的removeIf方法。例如,考虑在Java 8中添加到Collection接口的removeIf方法。此方法删除给定布尔方法(或Predicate函数式接口)返回true的所有元素。默认实现被指定为使用迭代器遍历集合,调用每个元素的谓词,并使用迭代器的remove方法删除谓词返回true的元素。 据推测,这个声明看起来像这样:默认实现被指定为使用迭代器遍历集合,调用每个元素的Predicate函数式接口,并使用迭代器的remove方法删除Predicate函数式接口返回true的元素。 根据推测,这个声明看起来像这样:

// Default method added to the Collection interface in Java 8

default boolean removeIf(Predicate<? super E> filter) {

????Objects.requireNonNull(filter);

????boolean result = false;

????for (Iterator<E> it = iterator(); it.hasNext(); ) {

????????if (filter.test(it.next())) {

????????????it.remove();

????????????result = true;

????????}

????}

????return result;

}

这是可能为removeIf方法编写的最好的通用实现,但遗憾的是,它在一些实际的Collection实现中失败了。 例如,考虑org.apache.commons.collections4.collection.SynchronizedCollection方法。 这个类出自Apache Commons类库中,与java.util包中的静态工厂Collections.synchronizedCollection方法返回的类相似。 Apache版本还提供了使用客户端提供的对象进行锁定的能力,以代替集合。 换句话说,它是一个包装类(条目 18),它们的所有方法在委托给包装集合类之前在一个锁定对象上进行同步。

Apache的SynchronizedCollection类仍然在积极维护,但在撰写本文时,并未重写removeIf方法。 如果这个类与Java 8一起使用,它将继承removeIf的默认实现,但实际上不能保持类的基本承诺:自动同步每个方法调用。 默认实现对同步一无所知,并且不能访问包含锁定对象的属性。 如果客户端在另一个线程同时修改集合的情况下调用SynchronizedCollection实例上的removeIf方法,则可能会导致ConcurrentModificationException异常或其他未指定的行为。

为了防止在类似的Java平台类库实现中发生这种情况,比如Collections.synchronizedCollection返回的包级私有的类,JDK维护者必须重写默认的removeIf实现和其他类似的方法来在调用默认实现之前执行必要的同步。 原来不属于Java平台的集合实现没有机会与接口更改进行类似的改变,有些还没有这样做。

在默认方法的情况下,接口的现有实现类可以在没有错误或警告的情况下编译,但在运行时会失败。 虽然不是非常普遍,但这个问题也不是一个孤立的事件。 在Java 8中添加到集合接口的一些方法已知是易受影响的,并且已知一些现有的实现会受到影响。

应该避免使用默认方法向现有的接口添加新的方法,除非这个需要是关键的,在这种情况下,你应该仔细考虑,以确定现有的接口实现是否会被默认的方法实现所破坏。然而,默认方法对于在创建接口时提供标准的方法实现非常有用,以减轻实现接口的任务(条目 20)。

还值得注意的是,默认方法不是被用来设计,来支持从接口中移除方法或者改变现有方法的签名的目的。在不破坏现有客户端的情况下,这些接口都不可能发生更改。

准则是清楚的。 尽管默认方法现在是Java平台的一部分,但是非常悉心地设计接口仍然是非常重要的。 虽然默认方法可以将方法添加到现有的接口,但这样做有很大的风险。 如果一个接口包含一个小缺陷,可能会永远惹怒用户。?如果一个接口严重缺陷,可能会破坏包含它的API。

因此,在发布之前测试每个新接口是非常重要的。 多个程序员应该以不同的方式实现每个接口。 至少,你应该准备三种不同的实现。 编写多个使用每个新接口的实例来执行各种任务的客户端程序同样重要。 这将大大确保每个接口都能满足其所有的预期用途。 这些步骤将允许你在发布之前发现接口中的缺陷,但仍然可以轻松地修正它们。 虽然在接口被发布后可能会修正一些存在的缺陷,但不要太指望这一点

原文地址:https://www.cnblogs.com/IcanFixIt/p/8313363.html

时间: 2024-10-06 13:03:32

Effective Java 第三版——21. 为后代设计接口的相关文章

Effective Java 第三版——14.考虑实现Comparable接口

Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将近8年的时间,但随着Java 6,7,8,甚至9的发布,Java语言发生了深刻的变化. 在这里第一时间翻译成中文版.供大家学习分享之用. ?14.考虑实现Comparable接口 与本章讨论的其他方法不同,compareTo方法并没有在Object类中声明. 相反,它是Comparable接口中的唯一方法.

《Effective Java 第三版》新条目介绍

前言 从去年的3月份起我就在开始读<Effective Java 第二版>,当然,我读的是中文版的:可能是我理解能力还不行,对于书中的内容总是感觉理解困难:就拿第一章的内容「创建和销毁对象」来说吧,这是我读的次数最多的一章,想必原因大家也是明白的,每次我读不下去的时候,我就从头开始读,所以,现在我对这本书的第一章是最为熟悉的了.后来,有一次我上网看到有网友说这本书确实和绝大部分的翻译书籍一样,对于有些原文中的内容翻译的不是很流畅,所以会导致阅读的人感觉难以理解:于是,我就斗胆下了本英文的原版来

Effective Java 第三版——10. 重写equals方法时遵守通用约定

Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将近8年的时间,但随着Java 6,7,8,甚至9的发布,Java语言发生了深刻的变化. 在这里第一时间翻译成中文版.供大家学习分享之用. 10. 重写equals方法时遵守通用约定 虽然Object是一个具体的类,但它主要是为继承而设计的.它的所有非 final方法(equals.hashCode.toStr

Effective Java 第三版——20. 接口优于抽象类

Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将近8年的时间,但随着Java 6,7,8,甚至9的发布,Java语言发生了深刻的变化. 在这里第一时间翻译成中文版.供大家学习分享之用. 20. 接口优于抽象类 Java有两种机制来定义允许多个实现的类型:接口和抽象类. 由于在Java 8 [JLS 9.4.3]中引入了接口的默认方法(default met

Effective Java 第三版——34. 使用枚举类型替代整型常量

Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将近8年的时间,但随着Java 6,7,8,甚至9的发布,Java语言发生了深刻的变化. 在这里第一时间翻译成中文版.供大家学习分享之用. Java支持两种引用类型的特殊用途的系列:一种称为枚举类型的类和一种称为注解类型的接口. 本章讨论使用这些类型系列的最佳实践. 34. 使用枚举类型替代整型常量 枚举是其合

Effective Java 第三版——3. 使用私有构造方法或枚类实现Singleton属性

Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将近8年的时间,但随着Java 6,7,8,甚至9的发布,Java语言发生了深刻的变化. 在这里第一时间翻译成中文版.供大家学习分享之用. 3. 使用私有构造方法或枚类实现Singleton属性 单例是一个仅实例化一次的类[Gamma95].单例对象通常表示无状态对象,如函数(条目 24)或一个本质上唯一的系统

Effective Java 第三版——12. 始终重写 toString 方法

Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将近8年的时间,但随着Java 6,7,8,甚至9的发布,Java语言发生了深刻的变化. 在这里第一时间翻译成中文版.供大家学习分享之用. 12. 始终重写 toString 方法 虽然Object类提供了toString方法的实现,但它返回的字符串通常不是你的类的用户想要看到的. 它由类名后跟一个"

Effective Java 第三版——18. 组合优于继承

Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将近8年的时间,但随着Java 6,7,8,甚至9的发布,Java语言发生了深刻的变化. 在这里第一时间翻译成中文版.供大家学习分享之用. 18. 组合优于继承 继承是实现代码重用的有效方式,但并不总是最好的工具.使用不当,会导致脆弱的软件. 在包中使用继承是安全的,其中子类和父类的实现都在同一个程序员的控制之

Effective Java 第三版——19. 如果使用继承则设计,并文档说明,否则不该使用

Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将近8年的时间,但随着Java 6,7,8,甚至9的发布,Java语言发生了深刻的变化. 在这里第一时间翻译成中文版.供大家学习分享之用. 19. 如果使用继承则设计,并文档说明,否则不该使用 条目 18中提醒你注意继承没有设计和文档说明的"外来"类的子类化的危险. 那么为了继承而设计和文档