如何在Java中Observer的update()中执行不同的操作？
我刚刚开始使用 Observable、Observer 及其 update() 方法，我不明白当不同的操作调用 <代码>notifyObservers()。
我的意思是，我的 Observable 类有几个不同的方法，最终调用 setChanged() 和 notifyObservers() 。根据调用的方法，UI（Swing）的某些部分需要更新。但是，Observer 类中只实现了一个 update() 方法。
我虽然将一些东西传递给 notifyObservers() 方法，然后我可以检查 update() 上的参数，但这感觉不是一个好方法。即使通过了，我应该通过什么？带有操作/方法简短描述的字符串？一个 int，就像一个动作/方法代码？还有别的事吗？
处理这种情况的最佳方法是什么？
I just started playing with Observable, Observer and it's update() method and I can't understand what should I do when different actions call notifyObservers().
I mean, my Observable class has a few different methods that call setChanged() and notifyObservers() in the end. Depending on the called method, some part of the UI (Swing) needs to be updated. However, there is only one update() method implemented in the Observer class.
I though of passing something to the notifyObservers() method and then I can check the argument on update() but it doesn't feel like a good way to do it. Even if it did, what should I pass? A string with a short description of the action/method? An int, like an action/method code? Something else?
What's the best way to handle this situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一般来说，当您调用 update() 时，您应该更新可观察到的所有内容。如果这不切实际，您可以将提示传递给notifyObservers()。
这本书说，观察者模式的后果之一是：
“意外的更新。因为观察者不知道彼此的存在，所以他们可能对改变主题的最终成本视而不见。一个看似无害的操作此外，未明确定义或维护的依赖标准通常会导致虚假更新，而这种更新很难追踪，这一
事实会加剧这个问题 。简单的更新协议没有提供有关主题发生了什么变化的详细信息，如果没有额外的协议来帮助观察者发现发生了什么变化，他们可能会被迫努力推断出变化。
”
同样在实现中，他们说：
“避免观察者特定的更新协议：推和拉模型。观察者模式的实现通常让主体广播有关更改的附加信息。主体将此信息作为参数传递给 Update。数量 只发送最多的信息。
在一个极端，我们称之为推送模型，主体向观察者发送有关变化的详细信息，无论他们是否愿意；在另一个极端，主体 。
拉模型强调主体对其观察者的无知，而推模型假设主体了解其观察者的需求，推模型可能会降低观察者的可重用性，因为主体类会做出假设 另一方面，拉模型可能效率低下，因为观察者类必须在没有主体帮助的情况下确定发生了什么变化。
”
in general you should update everything from the observable when you get a call to update(). if that is not practical, you can pass a hint to notifyObservers().
the gang-of-book says that one of the consequences of the observer pattern is:
"Unexpected updates. Because observers have no knowledge of each other's presence, they can be blind to the ultimate cost of changing the subject. A seemingly innocuous operation on the subject may cause a cascade of updates to observers and their dependent objects. Moreover, dependency criteria that aren't well-defined or maintained usually lead to spurious updates, which can be hard to track down.
This problem is aggravated by the fact that the simple update protocol provides no details on what changed in the subject. Without additional protocol to help observers discover what changed, they may be forced to work hard to deduce the changes.
"
also under implementation, they say:
"Avoiding observer-specific update protocols: the push and pull models. Implementations of the Observer pattern often have the subject broadcast additional information about the change. The subject passes this information as an argument to Update. The amount of information may vary widely.
At one extreme, which we call the push model, the subject sends observers detailed information about the change, whether they want it or not. At the other extreme is the pull model; the subject sends nothing but the most minimal notification, and observers ask for details explicitly thereafter.
The pull model emphasizes the subject's ignorance of its observers, whereas the push model assumes subjects know something about their observers' needs. The push model might make observers less reusable, because Subject classes make assumptions about Observer classes that might not always be true. On the other hand, the pull model may be inefficient, because Observer classes must ascertain what changed without help from the Subject.
"
update()是Object类型，因此您可以传递任何适当的内容。正如您所注意到的，该方法相当相比之下，维护 的类。EventListenerList在按指定使用时可以获得一定程度的运行时类型安全性。The second parameter to
update()is of typeObject, so you can pass anything appropriate. As you note, the approach is rather general. In contrast, a class that maintains anEventListenerListcan get a degree of run-time type safety when used as specified.