The Mediator Pattern offers a solution for managing dependencies between multiple Classes. Instead of Classes interacting and calling each other directly, the Mediator stands in the middle and directs the Logic (Sounds familiar, right? Like Proxy or Facade Pattern?).
The fundamental difference between Proxy, Facade Pattern, and Mediator Pattern is that Proxy and Facade Pattern are created from the perspective of the provider (the creator of the module, framework, package, or service).
Meanwhile, Mediator is created from the perspective of the feature developer, maintaining the codebase.
When Classes Conflict With Each Other :)
The example above shows that within a Dialog, the Button and TextField Classes are independent classes that need to interact directly with each other to check values and states for the purpose of product development. If one class changes, it can lead to changes in other classes. To minimize dependencies and make testing easier, the author used the Mediator Pattern - The Conflict Resolver.
Mediator Pattern - The Conflict Resolver
The Mediator Pattern introduces a Mediator object at the center, which groups the communication logic between interacting objects (called components). Instead of communicating directly, components send messages to the Mediator, which then forwards the calls or handles them appropriately based on the current state.
In this way, the components only depend on the Mediator's interface, and not directly on each other -> increasing independence.
Advantages and disadvantages of the Mediator Pattern
Follow my Youtube and Facebook channels to get more updates on knowledge!
@dantech