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

Is the use of the mediator pattern recommend?

提问by bodokaiser

I am currently reading http://addyosmani.com/resources/essentialjsdesignpatterns/book/#mediatorpatternjavascript

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

I understand the mediator pattern as some sort of object which sets up publish and subscribe functionality.

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

Usually I am setting up objects which already provide subscribe(), publish() methods. Concrete Objects extend this base object so that subscribe() and publish() are always registered as prototype attributes.

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

As I understand right the mediator pattern is used to add the publish-subscribe-methods to an object.

据我了解，中介模式用于将发布订阅方法添加到对象中。

What is the benefit of this practice? Isn't it a better practice to provide a base object with publish and subscribe functions than letting a mediator set up at construction?

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

Or have I understood the mediator pattern wrong?

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

Regards

问候

回答by Joseph

As what I have learned from similar posts some time ago:

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

• The mediator pattern provides a standard API for modules to use.

  Let's have an example:

  Your app's thousands of modules heavily rely on jQuery's $.post. If suddenly, your company had licensing issues and decided to move over to, for example, MooTools or YUI, would your look for all the code that uses $.postand replace them with something like MooTools.post?

  The mediator pattern solves this crisis by normalizing the API. What the modules know is that your mediator has a post function that can do AJAX post regardless of what library was used.

  //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
  

• The mediator serves as the "middle-man" for intermodule communication.

  One problem in newbie JS development is when modules are interdependent. That is when:

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

  But what if something is wrong in MyClassBand the developer took it out of the build. Would you look for and strip out all code in MyClassAthat uses MyClassBso that it does not break due to the absence of MyClassB?

  The mediator pattern's publishand subscribepattern solves this by making the module subscribe to an event instead of directly interfacing with the other modules. The mediator acts as a collection of callbacks/subscriptions that are fired when events are published.

  This "anonymous" subscribing results in partialloose-coupling. Modules would still need to know which modules to listen to or at least a set of events to listen to, but they are connected in a way that won't result in breakage if any one of them is taken out. All they know is that they subscribed to the event and will execute when that event happens - regardless of who fires it, if it fires at all, or if the trigger exists.

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

  让我们举个例子：

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

  中介者模式通过规范化 API 解决了这个危机。模块知道的是，您的中介器有一个 post 功能，无论使用什么库，它都可以执行 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模式通过使模块订阅事件而不是直接与其他模块交互来解决这个问题。中介器充当事件发布时触发的回调/订阅的集合。

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

回答by user1577390

You can achieve mediation without using eventing (pub/sub). In complex/sophisticated flows, it can be challenging to debug or reason about code that is purely event driven.

您可以在不使用事件 (pub/sub) 的情况下实现中介。在复杂/复杂的流程中，调试或推理纯事件驱动的代码可能具有挑战性。

For an example on how you can create a mediator without pub/sub, you can take a look at my project jQueryMediator: https://github.com/jasonmcaffee/jQueryMediator

有关如何在没有发布/订阅的情况下创建中介的示例，您可以查看我的项目 jQueryMediator：https: //github.com/jasonmcaffee/jQueryMediator