javascript - 是否建议使用中介模式？

我目前正在阅读http://addyosmani.com/resources/essentialjsdesignpatterns/book/#mediatorpatternjavascript

我将调解员模式理解为某种对象，它可以设置发布和订阅功能。

通常，我设置的对象已经提供了subscription()，publish()方法。具体对象扩展了此基础对象，以便始终将subscription()和publish()注册为原型(prototype)属性。

据我所知，中介者模式用于向对象添加publish-subscribe-method。

这种做法有什么好处？提供一个具有发布和订阅功能的基础对象比让中介在构建时更好的做法吗？

还是我理解调解员模式错误？

问候

最佳答案

正如我前段时间从类似文章中学到的:

中介者模式提供了供模块使用的标准API。

让我们举个例子:

您的应用程序的数千个模块严重依赖jQuery的$.post。如果突然，您的公司遇到了许可问题，并决定转到例如MooTools或YUI，您是否会查找所有使用$.post的代码并将其替换为MooTools.post这样的代码？

中介者模式通过标准化API解决了这一危机。这些模块知道的是，您的调解员具有发布功能，无论使用什么库，该功能都可以执行AJAX发布。

//module only sees MyMediator.post and only knows that it does an AJAX post
//How it's implemented and what library is used is not the module's concern

jQuery.post   -> MyMediator.post -> module
MooTools.post -> MyMediator.post -> module
YUI.post      -> MyMediator.post -> module

中介者充当模块间通信的“中间人”。

新手JS开发中的一个问题是模块是相互依赖的。那时:

MyClassA.something = MyClassB.method();
MyClassB.something = MyClassA.method();

但是，如果MyClassB出了问题并且开发人员将其从构建中删除，该怎么办。您是否会查找并剥离使用MyClassA的MyClassB中的所有代码，以使其不会由于缺少MyClassB而中断？

中介者模式的publish和subscribe模式通过使模块订阅事件而不是直接与其他模块交互来解决此问题。中介者充当事件发布时触发的回调/订阅的集合。

这种“匿名”订阅导致部分松耦合。模块仍然需要知道要听哪个模块，或者至少要听一组事件，但是它们的连接方式不会导致任何模块被破坏。他们所知道的只是他们订阅了该事件，并且将在该事件发生时执行-无论是谁触发，根本触发还是触发器存在。