是否推薦使用中介者模式？

Question

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

我將中介模式理解為某種設置發布和訂閱功能的對象。

通常我正在設置已經提供subscribe() 、 publish()方法的對象。 具體對象擴展了這個基礎對象，以便subscribe()和publish()總是注冊為原型屬性。

據我了解，中介模式用於將發布訂閱方法添加到對象中。

這種做法有什么好處？ 為基礎對象提供發布和訂閱功能不是比讓中介在構造時設置更好的做法嗎？

還是我理解錯了中介模式？

Answer 1

正如我前段時間從類似帖子中了解到的：

• 中介者模式為要使用的模塊提供了標准 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模式通過讓模塊訂閱事件而不是直接與其他模塊交互來解決這個問題。 中介器充當事件發布時觸發的回調/訂閱的集合。

  這種“匿名”訂閱導致部分松散耦合。 模塊仍然需要知道要偵聽哪些模塊或至少要偵聽一組事件，但是它們的連接方式不會在取出任何一個模塊時導致損壞。 他們只知道他們訂閱了該事件並將在該事件發生時執行 - 無論是誰觸發它，它是否觸發，或者觸發器是否存在。

Answer 2

您可以在不使用事件 (pub/sub) 的情況下實現中介。 在復雜/復雜的流程中，調試或推理純事件驅動的代碼可能具有挑戰性。

有關如何在沒有發布/訂閱的情況下創建中介的示例，您可以查看我的項目 jQueryMediator： https : //github.com/jasonmcaffee/jQueryMediator