Oop 观察者模式还是回调？

我必须设计一个

DownloadManager

，但我的主要问题是

DownloadManager

可以发送给

DownloadManager

的通知，比如

onUpdate（）

更新进度条，

onError（）

，

onFinish（）

，以某种方式，

DownloadManager

必须从其

Download

s接收此通知

我想到了两种可能的方法：

• 观察者模式
• 回调

观察者模式

基本上有1个观察者和N个观察者。在我的例子中，DownloadManager是一个观察者，下载的是观察者，所以关系是N个观察者1个观察者，正好相反

优点是将所有可能的通知集中在一个方法中，即观察员提供的

notify（）

或

update（）

（来自java）方法，在我的例子中，只有DownloadManager。我可以用通知的代码将参数传递给notify（）方法

劣势？我正在使用oop模式来完成一件可以通过回调轻松完成的事情。另外，N个观察者1个观察者这有点奇怪，至少在观察者模式中是这样的，因为这个模式是为1个观察者N个观察者设计的，所以我真的不会使用观察者模式

回拨

与观察者模式非常相似。DownloadManager实现了一个“监听器”（接口）。此侦听器实现通知函数onFinish（）、onUpdate（）等。然后此侦听器必须在所有下载中注册，因此当下载完成时，它将调用

listener.onFinish（）

。另外，我可以从下载中向这个方法传递参数，就像在observer模式中一样

优点：使用方便。 缺点：没有

我可能会使用回调，因为在我看来，对1个观察者N个观察者使用观察者模式是没有意义的

---

而您，将使用哪个选项？

回调FTW。它更简单，而且在绝大多数情况下，简单性以积极的方式影响项目的所有其他方面，包括开发、调试、优化、文档编制和进一步维护。

观察者更灵活/可扩展。在使用了您提到的observer模式之后，这不是很奇怪。模式毕竟只是指南，如果你需要改变它一点以适应你的需要，那么就去做吧

---

考虑当您有多个

下载管理器时的情况（对于您的特定情况，这可能不是一个有效的用例）。您需要同时注册这两个项目。如果你有更多，那么你将不得不注册所有这些。非常长的列表，另外您需要在
下载
s
中实现侦听器管理还有一个选项，它与观察者/回调方法相反。您可以将
DownloadManager
的客户端从节目的被动玩家转变为主动玩家。他们不会等待经理的消息，而是定期请求其状态

这样，您的下载过程在最终用户看来会更加顺畅。你就能更好地控制它

当然，您必须使用两个线程。或者，您必须教会
DownloadManager
分步工作，将控制权返回给其客户机，而不是运行一个牢不可破的工作。
observer更合适，因为Manager需要向多个实例发送请求

它很容易实现。在实现点上，它将在进度条功能和下载量以及总下载百分比方面具有更大的可扩展性
事实上，我的DownloadManager是一个单例。我的应用程序中只有一个实例。“回调。优点：易于使用。缺点：无。”我想您已经找到了答案。使用回调的一个缺点是它们增加了程序的耦合（因为它们通常会向使用回调的所有函数添加新参数）.我想你在这里再次解释的是一种观察者设计模式，它具有多种（类似重载）更新（可观察的o，对象arg）方法，以方便不同的状态更改更新。5年后。。。“正确的方式”似乎是观察者模式。看看大多数JavaScript API：它们正在用承诺取代回调。看看Angular 2：他们已经用可观测数据取代了回调和承诺。因此，回调很容易，但从长远来看，这不是一个好的选择。