Рекомендуется ли использовать шаблон посредника?

Я понимаю шаблон посредника как своего рода объект, который устанавливает функции публикации и подписки.

Обычно я настраиваю объекты, которые уже предоставляют методы subscribe(), publish(). Конкретные объекты расширяют этот базовый объект, так что subscribe() и publish() всегда регистрируются как атрибуты прототипа.

Как я понимаю, шаблон медиатора используется для добавления методов публикации-подписки к объекту.

Какая польза от этой практики? Не лучше ли предлагать базовый объект с функциями публикации и подписки, чем разрешить создание медиатора при построении?

Ответы

Ответ 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 implemented and what library is used is not the module concern

jQuery.post   -> MyMediator.post -> module
MooTools.post -> MyMediator.post -> module
YUI.post      -> MyMediator.post -> module
```
Медиатор служит "посредником" для межмодульной коммуникации.

Одна из проблем в разработке JB новичка - это когда модули взаимозависимы. Это когда:
```
MyClassA.something = MyClassB.method();
MyClassB.something = MyClassA.method();
```
Но что, если что-то не так в MyClassB, и разработчик вынул его из сборки. Вы бы искали и вычеркивали весь код в MyClassA, который использует MyClassB, чтобы он не прерывался из-за отсутствия MyClassB?

Шаблон шаблона медиатора publish и subscribe решает это, заставляя модуль подписаться на событие вместо прямого взаимодействия с другими модулями. Медиатор действует как набор обратных вызовов/подписки, которые запускаются при публикации событий.

Этот "анонимный" подписывает результаты в частичной развязке. Модулям все равно нужно будет знать, какие модули прослушивать или, по крайней мере, набор событий для прослушивания, но они связаны таким образом, что это не приведет к поломке, если какой-либо из них вынут. Все, что им известно, это то, что они подписались на событие и будут выполняться, когда это событие произойдет - независимо от того, кто его срабатывает, если он вообще срабатывает или существует триггер.

Ответ 2

Вы можете добиться посредничества без использования eventing (pub/sub). В сложных/сложных потоках может быть сложно отлаживать или рассуждать о коде, который управляется исключительно событием.

Для примера о том, как вы можете создать медиатор без pub/sub, вы можете посмотреть мой проект jQueryMediator: https://github.com/jasonmcaffee/jQueryMediator