Идеята на този design pattern е да създаде нещо като „контролна кула“ или централизиран начин отделни обекти да комуникират и работят заедно.
Един прост пример би бил чат програма с много участници, всеки от които ще приемем, че са отделни обекти, наследяващи или имплементиращи общ абсклас или интерфейс.
Те поотделно не се знаят един друг. Самият чатруум ще е нашият Медиатор, който ще разпределя съобщенията от, и за всеки участник.
Друг пример би бил различните графични среди, или например една HTML форма с различни контроли, които са отделни обекти но не се знаят един друг. При клик на радио бутон например, искаме неговият лейбъл да се покаже в текстово поле. Клас Dialog например може да организира взаимодействието между елементите, действайки като медиатор.
Mediator design pattern силно напомня на Observer design pattern, в този смисъл, че с Observer можем да реализираме програмно идеята на Mediator.
Друг възможен начин да реализираме програмно Mediator е като например имаме двата „участника“, между които искаме да посредничим, и единият вика метод на другият, като му предава например съобщението си и също и себе си (this), за да знае получателят кой го „безпокои“.
Ясно е, че при този начин трябва с абсклас/интерфейс да зададем обща структура на отделните участници.
Mediator design pattern също може да използва и Adapter design pattern за да „напасне“ комуникацията между „участниците“.
Advantages
Comprehension – The mediator encapsulate the logic of mediation between the colleagues. From this reason it’s more easier to understand this logic since it is kept in only one class.
Decoupled Colleagues – The colleague classes are totally decoupled. Adding a new colleague class is very easy due to this decoupling level.
Mediator design patter намалява coupling (зависимостта) между класовете на участниците, защото няма да има нужда те да „знаят“ един за друг и да „се съобразяват“ един с друг, за да могат да комуникират.
Simplified object protocols – The colleague objects need to communicate only with the mediator objects. Practically the mediator pattern reduce the required communication channels(protocols) from many to many to one to many and many to one.
Limits Subclassing – Because the entire communication logic is encapsulated by the mediator class, when this logic need to be extended only the mediator class need to be extended.
Disadvantages
Complexity – in practice the mediators tends to become more complex and complex. A good practice is to take care to make the mediator classes responsible only for the communication part. For example when implementing different screens the the screen class should not contain code which is not a part of the screen operations. It should be put in some other classes.
The mediator pattern is used to takes the role of a hub or router and facilitates the communication between many classes. A similarity can be made with the database systems. The mediator transform a hard to implement relation of many to many, where each calls has to communicate with each other class, in 2 relations, easy to implement, of many to one and one to many, where the communication is handled by the mediator class.
An inflexible way is to define a set of interacting objects ( Colleague1, Colleague2 ,…) by referring to (and update) each other directly, which results in many interconnections between them.
The Mediator design pattern provides a solution:
Define a separate Mediator object that encapsulates how a set of objects interact.
Objects interact with a Mediator object instead of interacting with each other directly.
Демек, „Участник 1“ иска да каже нещо на „Участник 2“. Не му го казва директно, а казва на Медиаторът да го стори.
Литература: