为什么属性改变了监听器而不是可观察的

Question

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

现在我即将开始我的主要应用程序并且刚刚阅读了这个

Making a JFrame and Observable Object

为什么海报建议不要使用observable而是告诉使用propertychangelistenr？使用observable有什么问题吗？

此致

Answer 1

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

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

我认为这就是为什么听众模特更可取的原因。

Answer 2

DejanLekic和其他人可能已经意识到，Observable不是interface。这是Java.util.Observable的整个问题！

Observable的用户必须继承它，而不是其他任何内容。

考虑Java.RMI或Listener events。

Answer 3

唯一正确的答案是“它取决于”。

当你不关心对象的变化时，

Observable是好的;您只想知道某些内容已更改并更新，例如对象属性的缓存。它的界面太粗糙了，但如果你只需要这样的东西，它可以节省时间。

另一方面，正如AlexR注意到的那样，你也不知道在手前传递了什么类型的参数（它甚至可以是null值！）。这使得用它做一些有用的事情变得更加困难。正确的侦听器类可以拥有更丰富的API，但代价是将Listener接口和事件类添加到项目中。

Answer 4

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

Answer 5

不同之处在于你如何使用它们。 Observable的大部分时间子类都没有特定的实现 - 你继承它只是为了得到一个新类型的Observable。另一方面，监听器实现特定的接口（或顶级EventListener接口），因此必须实现某些方法。