为什么属性更改侦听器而不是可观察的答案

【问题标题】：Why property change listener instead of observable为什么属性更改侦听器而不是可观察的
【发布时间】：2011-12-23 11:37:21
【问题描述】：

我在类设计方面遇到了问题，直到我发现了 observable（使用观察者设计模式）并因此使用它创建了一个小型应用程序来解决我的问题。我很高兴也很自豪我使用了一个好的原则来解决问题。

现在我即将启动我的主应用程序并且刚刚阅读了这篇文章

Making a JFrame and Observable Object

为什么建议发帖人不要使用 observable，而是告诉他使用 propertychangelistenr？使用 observable 有什么问题吗？

问候

【问题讨论】：

标签： java swing design-patterns

【解决方案1】：

区别在于您如何使用它们。大多数时候 Observable 的子类没有特定的实现——你从它继承只是为了获得一种新的 Observable 类型。另一方面，侦听器实现特定接口（或顶级 EventListener 接口），因此必须实现某些方法。

【讨论】：

【解决方案2】：

观察者模式和监听者模式非常相似。但是 Observer 有个弱点：所有的 observables 都是一样的。您必须实现基于instanceof 的逻辑并将对象转换为具体类型到Observable.update() 方法中。

听众是不同的。有很多听众类型。例如鼠标监听器、键盘监听器等。每个都有几个回调方法（即keyPressed()、keyReleased() 等）。因此，您永远不必在事件处理程序中实现应该回答“这是我的事件”问题的逻辑。

我认为这就是为什么侦听器模型更可取的原因。

【讨论】：

你是什么意思“所有可观察的都是一样的”？
Observable 只有一个处理所有事件的处理程序，并且必须实现区分它们的逻辑。侦听器对每个事件类型都有处理程序，因此实现无需样板代码。
现在很清楚了，我用“observer”这个词来表示你的“observable”，这是一个小小的措辞问题。

【解决方案3】：

DejanLekic 和其他人现在可能已经意识到，Observable 不是interface。这就是Java.util.Observable 的全部问题！

Observable 的用户必须继承它，没有别的。

考虑Java.RMI 或Listener events。

【讨论】：

【解决方案4】：

唯一正确的答案是“视情况而定”。

Observable 在您不关心对象发生什么变化时很好；您只想知道 something 更改和更新，例如对象属性的缓存。它的界面太粗糙了，但如果你只是需要这样的东西，它可能会节省时间。

另一方面，正如 AlexR 所注意到的，您也不知道事先传入了什么类型的参数（它甚至可以是 null 值！）。这使得用它做一些有用的事情变得更加困难。适当的监听器类可以拥有更丰富的 API，但代价是向您的项目添加监听器接口和事件类。

【讨论】：

【解决方案5】：

PropertyChangeListener 是 Observable 模式的一个特例。那就是我猜从设计的角度来看，这两种解决方案都很好。同时，据我所知，PropertyChangeListener 有一些内置支持，因此它可能需要更少的编码。 IE。见：http://download.oracle.com/javase/1.4.2/docs/api/java/beans/PropertyChangeSupport.html。

【讨论】：