Шаблон посредника против публикации / подписки

Question

Может кто-нибудь указать на основные различия между ними?

Кажется, что, по крайней мере, концептуально, эти два очень тесно связаны. Если бы я рискнул предположить, я бы сказал, что метод публикации / подписки является подмножеством шаблона посредника (поскольку посредник не обязательно должен использоваться в режиме публикации / подписки, но последний, похоже, требует своего рода посредника объект). Это близко к нему?

Answer 1

Как бы я описал разницу, в посреднике вас, вероятно, волнует, получит ли конечное приложение сообщение. Таким образом, вы используете это, чтобы гарантировать, кто получает сообщение. Принимая во внимание, что с pub / sub вы просто публикуете свое сообщение. Если есть подписчики, они их получат, но вам все равно.

Answer 2

Согласно этой странице , модель публикации-подписки является реализацией шаблона-посредника.

Edit

Следует отметить, что шаблоны проектирования называются "шаблоны "именно потому, что будут различия между каждой реализацией.Они не столько набор декретированных, канонических форм, сколько набор наблюдений за тем, как люди уже пишут программное обеспечение.Таким образом, на самом деле нет никакого способа, чтобы дизайн «строго» придерживался шаблона дизайна.

Answer 3

Реализация может быть одинаковой, но логически они разные (разница проста, но ее трудно увидеть).Ниже я объясню это простым способом.

Практически, при реализации шаблона публикации / подписки у вас будет по крайней мере объект с методами «опубликовать» и «подписаться».Но их может быть и больше, поэтому связь между компонентами не централизована по определению.

В реализации шаблона-посредника у вас будет объект JUST ONE с методами "publish" и "subscribe".Таким образом, общение «централизовано» по определению.

Answer 4

В книге GoF публикация / подписка известна как Шаблон наблюдателя . Шаблон посредника может быть реализован с использованием шаблона наблюдателя; но это не единственный способ реализации Посредника. Книга описывает это на странице 278.

Связь между коллегой и посредником . Коллеги должны общаться со своим посредником, когда происходит интересующее событие. Один из подходов состоит в том, чтобы реализовать посредника в качестве наблюдателя, используя шаблон наблюдателя. Коллегиальные классы действуют как субъекты, отправляя уведомления посреднику всякий раз, когда они меняют состояние. Посредник отвечает, распространяя результаты изменений другим коллегам.

Другой подход определяет специальный интерфейс уведомлений в Mediator, который позволяет коллегам быть более непосредственными в общении ... При общении с посредником коллега передает себя в качестве аргумента, позволяя посреднику идентифицировать отправителя.

Обратите внимание, что даже при реализации Посредника в качестве Наблюдателя он описывается как общение только среди своих коллег, тогда как Наблюдатель в целом, вероятно, будет связываться и с другими объектами.

Answer 5

Я думаю, что одним из основных отличий является контекст проблемы.

Хотя проблему можно решить с помощью любого шаблона, реальные проблемы:

1: «Сколько изменений, вызванных событиями, зависит от общего контекста?»

2: «Как часто слушатели должны меняться?»

Классический случай для шаблона-посредника лучше всего иллюстрирует это, когда у вас есть сложный пользовательский интерфейс со множеством компонентов, а обновление каждого из них имеет сложную взаимозависимость от состояния других подобных компонентов.

Хотя вы можете решить эту проблему с помощью шаблона pub / sub; где ваши компоненты прослушивают события и содержат логику, необходимую для обновления, объект контекста (вместе с событием) несет всю необходимую информацию. Здесь преимущество, очевидно, заключается в правильной инкапсуляции логики, относящейся к компоненту внутри себя. Недостатком является то, что если такие компоненты должны часто меняться, то вам придется полностью повторять эту логику в каждом новом компоненте, который вы вводите.

Использование посредника означает введение еще одного слоя и дальнейшее абстрагирование от компонентов. Эти компоненты становятся тоньше, так как они имеют дело только с представлением (внешний вид пользовательского интерфейса), поэтому их очень легко менять. Единственная проблема, с которой я сталкиваюсь при таком подходе, состоит в том, что логика обновления теперь, похоже, распространяется на другие компоненты, и любое обновление системы потребует изменения логики компонента и посредника, если поведение компонента также изменится.

Для меня это главная дилемма / компромисс, который мы должны решить. Пожалуйста, поправьте меня, если я ничего не понял правильно.