为什么要改变property listener而不是可观察

Question

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

现在，我即将开始我的主要应用和刚才读这

Making a JFrame and Observable Object

的海报建议不要使用可观察到的为什么，而是告知使用propertychangelistenr？使用observable有什么问题吗？

Regards

Answer 1

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

听众是不同的。有很多监听器类型。例如鼠标监听器，键盘监听器等。每个人都有几种回调方法（即keyPressed(),keyReleased()等）。所以，你永远不必执行应该回答“是我的事件”这个问题的逻辑到事件处理程序中。

我认为这就是为什么听者模型更可取。

Answer 2

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

Answer 3

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

Observable当你不关心对象有什么变化时，它是很好的;你只想知道有些东西已更改并更新，例如对象属性的缓存。它的界面太粗糙了，但如果你只是需要这样的东西，它可能会节省时间。另一方面，正如AlexR注意到的那样，你也不知道什么类型的参数事先通过了（它甚至可以是一个null值！）。这使得它很难做一些有用的事情。正确的监听器类可以有更丰富的API，但代价是将Listener接口和事件类添加到项目中。

Answer 4

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

Answer 5

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

Observable的用户必须从它继承，而不是别的。

考虑Java.RMI或Listener events。