观察者模式还是回调？

Question

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

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

• 观察者模式
• 回调

观察员模式

基本上有1个Observable和N Observers。在我的情况下，DownloadManager有一个Observer和下载Observables，因此关系是N Observables 1 Observer，恰恰相反。

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

缺点？我正在使用oop模式来完成一个可以通过回调轻松完成的事情。此外，N观察者1观察者它是奇怪的，至少对于观察者模式，因为这个模式是为1个可观察的N个观察者完成的，所以我真的不会使用观察者模式。

回调

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

优点：易于使用。 缺点：无。

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

你，哪个选项会用？

Answer 1

还有一个选项，与Observer / Callback方法相反。您可以将DownloadManager的客户从被动转为活动的演员。他们不会等待经理发来的消息，而是会定期请求其状态。

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

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

Answer 2

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

Answer 3

观察者更灵活/可扩展。在你为观察者模式提到的所有用法之后，这不是很奇怪。如果您需要根据自己的需求进行更改，那么Patts毕竟只是指导，然后去了。

考虑具有多个DownloadManagers的情况（可能这不是针对您的特定情况的有效用例）。您需要注册它们。如果你有更多，那么你将必须注册所有这些。相当长的列表，您需要在Download s

中实现侦听器管理

Answer 4

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

易于实施。在实施方面，它将在进度条功能方面更具可扩展性，并且每个下载多少和Total％Download