适当使用 Event-Listener 模式

Question

我很欣赏这可能不是一个正确/错误类型的问题，可能更多的是一种风格问题，但我经常发现自己在思考自定义 Event 和 EventListener 类的使用（过度使用？）。

我经常有一个类（通常是一个 GUI 组件），它需要让其他组件知道它的状态发生了一些变化。

我可以维护一个ChangeListeners 列表（或其他一些已定义的通用监听器类型），然后在状态更改时调用它们，例如：

for (final ChangeListener cl : changeListeners)
    cl.stateChanged(new ChangeEvent(this));

然后在监听器中检索值：

class SomeListener implements ChangeListener {
    @Override
    public void stateChanged(ChangeEvent e) {
        ((MyClass) e.getSource()).getSomeStateProperty();
        .
        .
        .
    }

但是，MyClass 的强制转换让我觉得这是一种不好的做法，因为侦听器类现在对 ChangeEvent 的内容做出了明确的假设，而 ChangeEvent 构造函数采用类型 Object .

所以我经常发现自己创建了一对自定义 Event 和 EventListener 类/接口，即

public interface SomeThingChangeListener extends EventListener {
    /**
     * Invoked when the target of the listener has changed some thing.
     *
     * @param e a SomeThingChangeEvent object
     */
     void someThingChanged (SomeThingChangeEvent e);
} 

对应的事件类包含对相关更改信息的引用（可能是对事件构造函数中的接口或抽象类的引用）。

然而，困扰我的事情是这些小型连接器类/接口的大量扩散，用于所有可能“发生”的“事情”，而这些“事情”可能只有一个具体的实现。

所以我想问题是；是尽可能地使用通用事件/侦听器，还是始终制作特定于类/事件的事件和侦听器？

我似乎创造了很多这样的主要原因是我经常想到两个（或更多）类之间的关联往往相当弱，它们通常在任何情况下都没有真正相互关联方式，但一个人可能对另一个人创建/修改的信息/状态感兴趣，但不关心源的细节。我发现观察者或事件/侦听器模式是一种将不相关类之间的耦合降至最低的好方法。

有什么想法吗？ 在此先感谢，
西蒙。

Answer 1

在我看来，为构成您的域模型的每个 event 定义特定类型是一种很好的做法（我确实更喜欢/大多数时候遵循）。拥有与不同事件类型一样多的事件侦听器可能会导致类污染。另一方面，通用侦听器方法导致通过instanceof 的序列确定事件类型或使用Visitor Pattern 来调度事件。 Visitor Pattern 将事件耦合到侦听器。也许能够消费多个事件的侦听器之间的折衷（更改相关事件的侦听器方法）将通过保留特定于事件的消费来减少不同侦听器的数量，避免instanceof 的序列。

适当的解决方案取决于具体项目，并且始终是许多方面的权衡。