是否可以将默认实现添加到代表侦听器的接口的方法中？答案

【问题标题】：Is it OK to add default implementations to methods of an interface which represents a listener?是否可以将默认实现添加到代表侦听器的接口的方法中？
【发布时间】：2015-09-07 14:20:20
【问题描述】：

我在项目中使用了某个库。这个库有一个接口，它有大约 15 个方法。

此接口的目的是使订阅库中生成的某些事件成为可能。应用程序中的监听器类可以实现该接口，并将自己注册为库中的监听器以接收事件。

这个接口中的所有方法实际上都是事件。可以有只需要从接口中的许多事件中接收一个或两个事件的侦听器。尽管监听器只对少数事件感兴趣，但监听器在扩展接口时必须实现所有方法。

所以我要求这个库的开发者为接口中的方法添加空的默认实现。

但库开发者拒绝添加默认实现，称这将违反 Java 最佳实践，并且在接口方法中使用默认实现违背了接口的目的。

但是，据我所知，此接口中的方法并未指定此接口的实现者应该能够执行的某些操作。这个接口中的方法定义了一个实现者可能感兴趣的事件。所以我看不出不添加默认实现的明确原因。

那么，向这个接口添加默认实现是否会破坏 Java 最佳实践？

【问题讨论】：

在 java 8 中，您可以指定接口方法的默认实现，使接口的实现者可以选择实现该方法。
这真是一个意见问题；没有客观的答案。但请记住，即使库开发人员不想向接口添加默认实现，您也可以创建自己的接口，扩展库中的接口并添加空的默认实现。你的“真正的”实现类可以实现那个。
无论如何，这显然是API设计者的错，他需要提供更好的解决方案。
可笑的是，在计算机行业，人们到处乱讲大词，却没人知道它们的意思。我们为什么不停止像一些基本的圣战分子那样说话，而专注于实际问题，例如，有没有更简单的方法来使用你的 API。
@biziclop 我完全同意。一个好的问题需要上下文，这个问题确实提供了。

标签： java interface

【解决方案1】：

但是库开发者拒绝添加默认实现，声明它会违反 Java 最佳实践并使用默认值接口方法中的实现违背了接口。

在引入默认接口方法之前，此参数有效。现在你的同事不得不争辩说，Java 8 的 JLS 变态接口和 JDK 现在包含违背接口目的的类。这仍然是一个可行的极端观点，但没有结果。

您可以通过从库接口派生自己的接口并为所有继承的方法提供默认的空实现来避免讨论。

public interface MyInterface extends LibraryInterface {
    @Override default public void event1() {
    }

    ...
}

或者你们都可以查看以下设计，这对我来说似乎是可疑的，并且导致了你们对接口中默认方法的讨论：

即使监听器只对少数事件感兴趣，监听器 在扩展接口时必须实现所有方法。

一种解决方案可能是简单地将大界面拆分为许多较小的界面。

【讨论】：

【解决方案2】：

库开发者对此有误（恕我直言，我什至不敢省略）。

过去在 Java 中引入了许多帮助程序（抽象和具体）类的原因之一就是缺少像默认接口方法这样的特性（例如 Swing 中的适配器类，它与您所关心的问题非常相似正在询问）。

如果没有误用，在某些情况下需要多重继承，而且众所周知，通过在 Java 中扩展“帮助”类，我们失去了从其他任何东西继承的能力。

其实这个在官方Java tutorial，“抽象类与接口的比较”一节中提到过：

如果这些陈述中的任何一个适用于您的，请考虑使用接口情况：

您希望不相关的类会实现您的接口。例如实现了接口 Comparable 和 Cloneable 许多不相关的类。

您想指定特定数据类型的行为，但不关心谁实现其行为。

您想利用类型的多重继承。

我认为第二点和第三点非常适合您的用例。

【讨论】：

【解决方案3】：

由于默认方法使我们能够在不破坏实现该接口的类的情况下向接口添加新功能，因此它绝对不是一个好的做法，因为它结合了接口和抽象类的优点，但既然这不是一个选项，我会强烈建议您提供自己的骨架实现类，因为这种“方法”在 Java 中的 Collections Framework 中被使用，这只是我的拙见。

【讨论】：