将主干与发布/订阅解耦

Decoupling backbone with pub/sub

本文关键字：解耦      更新时间：2023-09-26

我正在改进我使用backbone/require的方式，我发现让模块耦合是多么糟糕的做法(当时我不理解解耦)。

我开始玩MinPubSub和理解，在大多数情况下，但是，从我读到的，其他模块不应该订阅其他模块(这使得它耦合?)。相反，它们应该是所有模块之间的中介，告诉它们如何交互。

我假设此中介已订阅到所有模块，并且所有模块都已订阅到中介?

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

对不起，这是一个笼统的问题，试图把我的头脑围绕这个概念，并找到一个合适的例子，它广泛使用。

咳咳。publish - sub方法是中介模式的实现。您的中介是您的发布订阅处理程序。

让我澄清一下。在您的pubsub模型中，您注册一个通道并向其发布。任何潜在的监听程序都将按照它们订阅的顺序获取你发布的内容。

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

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

(直接摘自你最喜欢的百科全书)

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

  1. 模块用自己的名字注册通道
  2. 其他模块通过在其通道
    3. 上发布以字面名称引用它。

这是事件发布/订阅模型失效的地方，因为它在理论上是解耦的，但在实践中，您需要知道模块的确切名称。让你的事件足够通用，这样你就可以在不丢失函数的情况下就地换出模块，并防止/避免直接使用其他模块，这样你就可以很好地进行耦合了。

如果有不清楚的地方，请告诉我，我会尽量澄清。

有趣的是，我很喜欢使用的一个库叫做Mediator。

网站上有很好的例子，但是很粗糙:

$.getJSON('url/to/json', function(json) {
    mediator.publish('myData:loaded', {response: json});
});
// Somewhere else
mediator.subscribe('myData:loaded', function(json) {
    // Do something
});
相关文章：