javascript - 是否推荐使用中介者模式？

Question

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

我将中介模式理解为某种设置发布和订阅功能的对象。

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

据我所知，调解器模式用于将发布-订阅-方法添加到对象。

这种做法有什么好处？为基础对象提供发布和订阅功能，这不是比让中介在构造时设置更好的做法吗？

还是我对中介模式的理解有误？

Answer 1

正如我前段时间从类似帖子中了解到的那样:

• 中介者模式为模块提供了一个标准的 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 模式通过让模块订阅事件而不是直接与其他模块交互来解决这个问题。调解器充当事件发布时触发的回调/订阅的集合。

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