https://stackoverflow.com/questions/22425314
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianIn the Mediator pattern, "communication between objects is encapsulated with a mediator object." The goal is to achieve higher cohesion in classes by leaving the communication routing details in the mediator. The objects are directly coupled to the mediator and loosely coupled to each other.
In the Enterprise Service Bus architecture, "all customer services communicate in the same way with the ESB: the ESB translates a message to the correct message type and sends the message to the correct producer service."
To me, it seems more abstract than a GoF Mediator, whose examples tend to be related to a specific application. For example, a user interface behavior might specify that when a user clicks on an item in a list, the clicked item should be copied into a text box. This kind of behavioral logic is pretty application specific, but it is hard to maintain that logic if it's spread among the collaborating classes (e.g., the Item List and the Text Box each manage some part of the control). Spreading out that logic makes the collaborating objects less cohesive. A GoF Mediator centralizes this application logic, so the Item List doesn't know about Text Boxes, etc.
I see ESB as providing routing services, and it might not be so easy to customize it for a specific application's behavior. For example, entities still need to know about each other for communication, but the details have been abstracted. Behavior is defined in rules. I can see ESB as a general purpose Mediator, but the abstractions to provide generality might make it harder to understand (less cohesive, finally) than a GoF Mediator for a given application.
ESB is more of an architectural pattern (generalized services) whereas a Mediator can be a very application-specific pattern.
