0

我正在改进我使用主干/需求的方式，我发现了将模块耦合起来的做法有多糟糕（我当时不了解解耦）。

我开始玩MinPubSub并且在很大程度上理解了这一点，但是根据我的阅读，其他模块不应该订阅其他模块（这使得它耦合？）。相反，他们应该是所有模块之间的中介，告诉他们如何交互。

我假设这个中介订阅了所有模块并且所有模块都订阅了中介？

我不知道如何实现这一点，但还没有找到一个关于如何用主干实现它的可靠代码示例，任何关于将 pubsub 添加到主干的帮助将不胜感激。

抱歉，这是一个一般性的问题，试图围绕这个概念展开思考，并找到一个广泛使用的体面示例。

4

2 回答 2

2

咳咳。pubsub 方法是中介者模式的一种实现。您的调解员是您的 pubsub 处理程序。

让我澄清一下。在您的 pubsub 模型中，您注册一个频道并发布到它。那里的任何可能正在收听的内容都会按照他们订阅的顺序获得您发布的任何内容。

将此与中介模式的正式定义进行对比：

使用中介者模式，对象之间的通信被封装在中介者对象中。对象不再直接相互通信，而是通过中介进行通信。这减少了通信对象之间的依赖关系，从而降低了耦合度。

（直接摘自你最喜欢的百科全书）

这对你意味着什么？只要你不做我认识的人曾经做过的事，你就没事。这绝对是您要避免的：

  1. 模块用自己的名字注册一个通道
  2. 其他模块通过在其频道上发布来通过字面名称引用它

这是事件发布/订阅模型崩溃的地方，因为它在理论上是解耦的，但在实践中，您需要知道模块的确切名称。使您的事件足够通用，以便您可以在不丢失功能的情况下就地交换模块，并防止/避免直接访问其他模块，并且您可以很好地耦合。

如果其中任何一个不清楚，请告诉我，我会尝试澄清。

于 2013-04-12T22:05:45.007 回答
2

有趣的是，我非常喜欢的一个库叫做Mediator。

它在网站上有很好的例子，但粗略地说：

$.getJSON('url/to/json', function(json) {
    mediator.publish('myData:loaded', {response: json});
});

// Somewhere else
mediator.subscribe('myData:loaded', function(json) {
    // Do something
});
于 2013-04-12T22:10:40.433 回答