是否推荐使用中介模式?

时间:2012-09-21 16:21:59

标签: javascript design-patterns javascript-events mediator

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

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

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

据我所知,中介模式用于将发布 - 订阅 - 方法添加到对象。

这种做法有什么好处?为基础对象提供发布和订阅功能,而不是让构建器在构造中设置是不是更好的做法?

或者我理解调解员模式错了吗?

此致

2 个答案:

答案 0 :(得分:21)

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

  • 介体模式为要使用的模块提供标准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的{​​{1}}中的所有代码,以便它不会因MyClassB的缺席而中断?

    中介模式的MyClassBpublish模式通过使模块订阅事件而不是直接与其他模块接口来解决这个问题。中介充当发布事件时触发的回调/订阅的集合。

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

答案 1 :(得分:3)

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

有关如何创建没有pub / sub的介体的示例,您可以查看我的项目jQueryMediator: https://github.com/jasonmcaffee/jQueryMediator