假设有一个模块 A 使得模块 B 和 C 依赖于它。模块 A 支持侦听器模式，即 B 和 C 等模块可以侦听 A 生成的事件。因此，模块 A 与其侦听器分离。现在我们想要一些可以共同定义模块 A 的合约的合约（Java 中的接口）。
问题是在合约中插入监听器。我应该在合同中添加“public addListener（Listener listener）”之类的功能吗？另一种方法是使用实现侦听器部分的抽象类并将其他功能保留为抽象。我真的不想扩展类，因为在某个时候，如果我们决定在一个类中实现两个合同，那么这是不可能的。您能否讨论上述案例，并感谢您对相关主题的任何见解。
为什么我想要合同中的听众？这是因为如果有一天有人重写模块 A，听 A 的模块不应该分解。如果这不是一个好主意，请告诉我。
编辑：问题之一是我想让监听器/事件成为合同的一部分，以便可以轻松地完成未来的更改/重新实现。模块 A 早些时候触发了特定事件 E 不应该发生，但现在新的实现将其变为事件 B，因为程序员不知道事件（因为它不是合同的一部分）。这种方法的一个问题是我强迫程序员触发这些事件并使用基于事件的系统。
我肯定会根据侦听器接口定义 A，使用addListener（并且可能removeListener）公共方法和受保护notifyListeners方法（或者可能更多，取决于侦听器接口的复杂性）。
请注意，模块 B 和 C 也可能不实现侦听器接口；他们可以使用单独的侦听器对象（甚至可能是匿名内部类）。
一般来说，我不会实现抽象的监听器类；将其留给每个侦听器实现。如果侦听器接口声明了许多方法，但并非所有方法都适用于任何特定客户端，则例外情况。然后，实现一个对每个方法都不执行任何操作的基侦听器类可能会很有用。例如，可以在java.awt.MouseAdapter实现各种鼠标相关监听器接口的类中看到这种方法。
监督者模式是一种很好的解耦方式。
在 observalble 类中添加 addListener 和 removeListeners 方法不是一个好主意，因为它会导致代码重复（如果没有使用抽象实现）。
更好的解决方案是定义具有两个方法 addListener、removeListener 和 fireEvent 方法的 Registration 类。在这种情况下，Obeservable 类将只实现接口，例如 MyObservable，仅此而已。
以下链接将帮助您了解有关注册类的更多信息： Java 中的 EventBus