Javascript 推荐使用中介模式吗？_Javascript_Design Patterns_Mediator

Javascript 推荐使用中介模式吗？

javascript design-patterns

Javascript 推荐使用中介模式吗？,javascript,design-patterns,mediator,Javascript,Design Patterns,Mediator,我现在正在读书我将中介模式理解为某种设置发布和订阅功能的对象通常我设置的对象已经提供了subscribe（），publish（）方法。具体对象扩展了这个基本对象，因此subscribe（）和publish（）始终注册为原型属性正如我正确理解的那样，中介模式用于向对象添加发布-订阅方法这种做法的好处是什么？提供具有发布和订阅功能的基本对象不是比在构建时设置中介更好吗？或者我对中介模式的理解有误吗？正如我不久前从类似帖子中学到的：中介模式为模块提供了一个标准API 让我们举个例子：你

我现在正在读书

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

通常我设置的对象已经提供了

subscribe（）

，

publish（）

方法。具体对象扩展了这个基本对象，因此

subscribe（）

和

publish（）

始终注册为原型属性

正如我正确理解的那样，中介模式用于向对象添加发布-订阅方法

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

或者我对中介模式的理解有误吗？

正如我不久前从类似帖子中学到的：

中介模式为模块提供了一个标准API
让我们举个例子：
你的应用程序的数千个模块严重依赖jQuery的
```
$.post
```
。如果您的公司突然出现许可问题，并决定转移到MooTools或YUI，您是否会查找所有使用
```
$.post
```
的代码，并将其替换为类似
```
MooTools.post
```
中介模式通过规范化API解决了这一危机。模块所知道的是，您的中介有一个post函数，它可以执行AJAX post，而不管使用了什么库
```
//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
```
模式通过使模块订阅事件而不是直接与其他模块接口来解决这个问题。中介器充当事件发布时触发的回调/订阅的集合
这种“匿名”订阅导致部分松耦合。模块仍然需要知道要侦听的模块或至少要侦听的一组事件，但它们的连接方式不会导致任何一个模块被取出时发生损坏。他们所知道的只是他们订阅了该事件，并将在该事件发生时执行——不管是谁触发该事件、是否触发该事件，或者触发器是否存在

您可以在不使用事件（pub/sub）的情况下实现调解。在复杂/复杂的流中，调试纯事件驱动的代码或对其进行推理可能是一项挑战

有关如何在没有发布/订阅的情况下创建中介的示例，请查看my project JQueryMedia：

中介是否将其发布和订阅函数注册到构造函数中的对象？为什么我不能对所有事件使用全局中介？当使用例如requirejs时，中介不是必须是一个单例吗？@kyogron是的，中介就像一个单例，收集订阅并在调用时激发订阅。但有理由认为你会有不止一个调解人。为了清晰起见，我建议你看一下这个主题（他有幻灯片和图表）以及做这个模式的例子。@JosephDreamer在你的例子中，我觉得它更像是一个门面模式而不是中介？我错过了什么吗？@hguser第一部分是正面。第二部分是调解人。