Шаблон посредника vs публикация / подписка
может ли кто-нибудь указать на основные различия между ними?
кажется, что, по крайней мере, концептуально, они очень тесно связаны. Если бы я рискнул предположить, я бы сказал, что метод публикации/подписки является подмножеством шаблона медиатора (поскольку медиатор не обязательно должен использоваться в манере публикации/подписки, но последний, похоже, требует своего рода объекта медиатора). Это близко к нему?
4 ответов
Как бы я описал разницу в том, что в медиаторе вы, вероятно, заботитесь о том, получает ли конечное приложение сообщение. Таким образом, вы используете это, чтобы гарантировать, кто получает сообщение. В то время как с pub/sub вы просто публикуете свое сообщение. Если есть какие-либо подписчики, они получат его, но вам все равно.
по данным на этой странице, модель публикации-подписки является реализацией шаблона посредника.
редактировать
Я должен отметить, что шаблоны проектирования называются "шаблонами" именно потому, что между каждой реализацией будут различия. Это не столько набор предписанных канонических форм, сколько набор наблюдений над тем, как люди уже пишут программное обеспечение. Так что на самом деле нет никакого способа для дизайна " строго" придерживайтесь Шаблона дизайна.
реализация может быть одинаковой, но логически они разные (разница проста, но ее трудно увидеть). Я объясню это простым способом ниже.
Pratically, в реализации шаблона публикации / подписки у вас будет по крайней мере объект с методами "опубликовать" и "подписаться". Но вы также можете иметь их больше, поэтому связь между компонентами не централизована по определению.
в осуществлении посредника шаблон у вас будет только один объект с методами "опубликовать"и " подписаться". Таким образом, коммуникация "централизована" по определению.
Я думаю, что одним из основных моментов различия является контекст проблемы.
хотя проблема может быть решена либо с узором, с вопросом:
1: "насколько изменения, вызванные событиями, зависят от общего контекста ?"
2: "Как часто слушатели должны меняться?"
классический случай для шаблона медиатора лучше всего иллюстрирует это, когда у вас есть сложный пользовательский интерфейс с большим количеством компонентов и обновление на каждом из них имеет сложную взаимозависимость от состояния других подобных компонентов.
хотя вы можете решить эту проблему с шаблоном pub/sub; в котором ваши компоненты прослушивают события и содержат логику, необходимую для обновления, объект контекста (вместе с событием) несет всю необходимую информацию. Здесь преимущество, очевидно, заключается в правильной инкапсуляции логики, относящейся к компоненту внутри себя. Недостатком является то, что если такие компоненты должны меняться часто вам приходится полностью реплицировать эту логику в каждом новом компоненте, который вы вводите.
использовать медиатор-это ввести другой слой и далее абстрагироваться от компонентов. Эти компоненты становятся тоньше, поскольку они имеют дело только с представлением (внешний вид пользовательского интерфейса), поэтому их очень легко изменить. Единственная проблема с этим подходом заключается в том, что логика обновления теперь, похоже, распространяется на другие компоненты, и любое обновление системы потребует изменения компонента и посредник, если поведение компонента также должно измениться.
для меня это главная дилемма / компромисс, который нам нужно решить. Пожалуйста, поправьте меня, если я ничего не правильно.