观察者模式还是回调？
我必须设计 DownloadManager，但我的主要问题与 Download 可以发送到 DownloadManager 的通知有关，例如 < code>onUpdate() 更新进度条、onError()、onFinish() 等。不知何故，DownloadManager 有从其下载接收此通知。
我想到了两种可能的方法：
- 观察者模式
- 回调
观察者模式
基本上有 1 个 Observable 和 N 个观察者。在我的例子中，DownloadManager 是一个观察者，并且下载了 Observables，所以关系是 N Observables 1 Observer，正好相反。
优点是将所有可能的通知集中在一个方法中，即来自观察者的 notify() 或 update() （来自 java）方法，在我的例子中只有 DownloadManager 。我可以使用通知代码将参数传递给 notify() 方法。
缺点？我正在使用 oop 模式来完成可以通过回调轻松完成的事情。另外，N 个可观察者 1 个观察者这很奇怪，至少对于观察者模式来说是这样，因为这个模式是为 1 个可观察者 N 个观察者完成的，所以我真的不会使用观察者模式。
回调
与观察者模式非常相似。 DownloadManager 实现了一个“监听器”（接口）。该监听器实现了 onFinish()、onUpdate() 等通知函数。然后该监听器必须在所有下载中注册，因此当下载完成时，它将调用 listener.onFinish()。此外，我可以从下载中将参数传递给此方法，就像在观察者模式中一样。
优点：使用方便。 缺点：无。
我可能会使用回调，因为在我看来，对 1 个观察者 N 个可观察量使用观察者模式是没有意义的。
而你，会使用哪个选项？
I have to do a design of a DownloadManager, but my main question is related to the notifications that a Download can send to the DownloadManager like onUpdate() to update a progress bar, onError(), onFinish(), etc. Somehow the DownloadManager has to receive this notifications from its Downloads.
I've thought 2 possible ways:
- Observer pattern
- Callbacks
Observer pattern
Basically there are 1 Observable and N Observers. In my case the DownloadManager has te be an Observer and the Downloads the Observables, so the relation is N Observables 1 Observer, just the opposite.
The advantage is to centralize all the possible notifications in one method, the notify() or update() (from java) method from the Observers, in my case only the DownloadManager. I can pass a param to the notify() method with the code of the notification.
Disadvantage? I'm using an oop pattern for a thing that can be done easily with a callback. Also, N observables 1 observer it's something weird, at least with the observer pattern because this pattern was done for 1 observable N observers, so I really won't be using the observer pattern.
Callback
Very similar to the observer pattern. The DownloadManager implements a "listener" (interface). This listener implements the notification functions onFinish(), onUpdate(), etc. Then this listener must be registered in all Downloads, so when a Download finishes it will call listener.onFinish(). Additionally I can pass parameters to this methods from the Downloads, like in the observer pattern.
Advantage: Easily usage.
Disadvantage: None.
I will probably use a callback because in my opinion it makes no sense to use an observer pattern for 1 observer N observables.
And you, which option will use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
回调 FTW。它更简单，并且在绝大多数情况下，简单性会以积极的方式影响项目的每个其他方面，包括开发、调试、优化、文档记录和进一步维护。
Callbacks FTW. It is simpler, and in the vast majority of cases, simplicity influences every other aspect of the project in a positive way, including development, debugging, optimization, documentation and further maintenance.
观察者更加灵活/可扩展。在您提到观察者模式的所有用法之后，这并不奇怪。模式毕竟只是指导方针，如果您需要对其进行一些更改以满足您的需求，那就去做吧。
考虑当您有多个
DownloadManager时的情况（对于您的特定情况，这可能不是一个有效的用例）。您需要注册它们。如果您有更多，则必须将其全部注册。列表相当长，而且您需要在Download中实现侦听器管理The observer is more flexible/scalable. Is not that weird after all the usage you mentioned for the observer pattern. Patters are after all just guidlines, if you need to change it a bit to fit your needs then go for it.
Consider the case when you have multiple
DownloadManagers(maybe this is not a valid use case for your particular situation). You will need to register both of them. If you have even more then you will have to register all of them. Pretty long list, plus you need to implement listeners management in theDownloads还有一种选择，与观察者/回调方法相反。您可以将
DownloadManager的客户端从节目的被动玩家转变为主动玩家。他们不会等待经理的消息，而是定期询问其状态。这样，您的下载过程对于最终用户来说会显得更加顺畅。而且你将能够更好地控制它。
当然，您必须使用两个线程。或者，您必须教
DownloadManager逐步工作，将控制权返回给客户端，而不是运行一项牢不可破的工作。There is also one option, which is opposite to Observer/Callback approach. You can turn clients of
DownloadManagerfrom passive to active players of the show. Instead of waiting for a message from the manager they will regularly request its status.This way your download process will look much smoother to the end-user. And you will be able to control it better.
Of course, you will have to use two threads. Or you will have to teach the
DownloadManagerto work in small steps, returning control to its client, instead of running one unbreakable piece of work.observer 更合适，因为 Manager 需要向许多实例发送请求。
它很容易实现。在实施点上，它将在进度条功能以及每个下载量和总下载百分比方面更具可扩展性
observer is more suitable because Manager need to send request to many instances.
It is easy to implement. In implementation point of it will be more scalable in terms of progress bar functionality and how much downloaded each one and Total % Download