观察者模式还是回调？答案

【问题标题】：Observer pattern or Callback?观察者模式还是回调？
【发布时间】：2011-01-05 22:57:01
【问题描述】：

我必须设计DownloadManager，但我的主要问题与Download 可以发送到DownloadManager 的通知有关，例如onUpdate() 以更新进度条onError()， onFinish() 等。不知何故，DownloadManager 必须从其Downloads 接收此通知。

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

观察者模式
回调

观察者模式

基本上有 1 个 Observable 和 N 个 Observers。在我的例子中，DownloadManager 是一个 Observer，而下载 Observables，所以关系是 N Observables 1 Observer，正好相反。

优点是将所有可能的通知集中在一种方法中，即来自 Observers 的 notify() 或 update()（来自 java）方法，在我的例子中只有 DownloadManager。我可以使用通知的代码将参数传递给 notify() 方法。

缺点？我将 oop 模式用于可以通过回调轻松完成的事情。另外，N observables 1 observer 这有点奇怪，至少对于观察者模式来说是这样，因为这种模式是为 1 observable N 观察者完成的，所以我真的不会使用观察者模式。

回调

非常类似于观察者模式。 DownloadManager 实现了一个“监听器”（接口）。这个监听器实现了onFinish()、onUpdate()等通知函数。然后这个监听器必须在所有下载中注册，所以当一个下载完成时它会调用listener.onFinish()。此外，我可以从下载中将参数传递给此方法，就像在观察者模式中一样。

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

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

而你，将使用哪个选项？

【问题讨论】：

"回调。优点：易于使用。缺点：无。"我想你已经找到了答案。
使用回调的一个缺点是它们增加了程序的耦合度（因为它们通常会为所有使用它们的函数添加一个新参数）。
我认为回调你在这里再次解释的观察者设计模式具有多个（类似于重载）更新（可观察的 o，对象 arg）方法，以方便不同的状态更改更新。

标签： oop design-patterns

【解决方案1】：

还有一个选项，与观察者/回调方法相反。您可以将DownloadManager 的客户从被动转为主动参与。他们将定期请求其状态，而不是等待经理的消息。

这样，您的下载过程对最终用户来说会更加顺畅。并且您将能够更好地控制它。

当然，您必须使用两个线程。或者你将不得不教DownloadManager 以小步骤工作，将控制权交还给它的客户，而不是运行一个牢不可破的工作。

【讨论】：

【解决方案2】：

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

【讨论】：

5 年后......“正确的方式”似乎是观察者模式。查看大多数 JavaScript API：它们正在用 Promises 替换回调。看看 Angular 2：他们已经用 Observables 替换了回调和 Promises。所以回调很容易，但从长远来看不是一个好的选择。

【解决方案3】：

观察者更灵活/可扩展。在您提到观察者模式的所有用法之后，这并不奇怪。模式毕竟只是指导方针，如果您需要对其进行一些更改以满足您的需求，那就去吧。

考虑您有多个DownloadManagers 的情况（对于您的特定情况，这可能不是一个有效的用例）。您需要同时注册它们。如果你有更多，那么你将不得不注册所有这些。很长的列表，另外你需要在Downloads 中实现监听器管理

【讨论】：

其实我的DownloadManager是一个单例的。我的应用程序中只有一个实例。

【解决方案4】：

observer 更适合，因为 Manager 需要向多个实例发送请求。

很容易实现。在实现方面，它在进度条功能以及每个下载量和总下载百分比方面更具可扩展性

【讨论】：