为什么属性改变了监听器而不是可观察的
我遇到了类设计的问题，直到我发现了observable（使用观察者设计模式）并因此创建了一个使用它的小应用程序来解决我的问题。 我很高兴和自豪，我用一个好的原则来解决问题。
现在我即将开始我的主要应用程序并且刚刚阅读了这篇文章
制作JFrame和Observable对象
为什么海报建议不要使用observable而是告诉使用propertychangelistenr？ 使用observable有什么问题吗？
问候
Observer和Listener模式非常相似。 但观察者有一个弱点：所有可观测量都是相同的。 您必须实现基于instanceof和将对象转换为具体类型的逻辑到Observable.update()方法中。
听众是不同的。 有很多听众类型。 例如鼠标监听器，键盘监听器等。每个都有几个回调方法（即keyPressed() ， keyReleased()等）。 因此，您永远不必实现应该在事件处理程序中回答“是我的事件”这一问题的逻辑。
我认为这就是为什么听众模型更可取的原因。
DejanLekic和其他人可能已经意识到， Observable不是一个interface 。 这是Java.util.Observable的整个问题！
Observable的用户必须inheritance它，而不是其他任何东西。
考虑Java.RMI或Listener events 。
唯一正确的答案是“它取决于”。
当您不关心对象的变化时， Observable是好的; 你只想知道改变了什么，并更新了对象属性的缓存。 它的界面太粗糙，但如果您只需要这样的东西，它可能会节省时间。
另一方面，正如AlexR注意到的那样，你也不知道在手之前传递了什么类型的参数（它甚至可以是null值！）。 这使得用它做一些有用的事情变得更加困难。 正确的侦听器类可以拥有更丰富的API，但代价是将Listener接口和事件类添加到项目中。
PropertyChangeListener是Observable模式的特例。 这就是我认为从设计角度来看这两种解决方案都很好。 同时据我所知，PropertyChangeListener有一些内置的支持因此可能需要更少的编码。 IE浏览器。 请参阅： http ： //download.oracle.com/javase/1.4.2/docs/api/java/beans/PropertyChangeSupport.html 。
不同之处在于你如何使用它们。 Observable的大多数时间子类都没有特定的实现 – 你inheritance它只是为了获得一种新类型的Observable。 另一方面，监听器实现特定的接口（或顶级EventListener接口），因此必须实现某些方法。