Mediator
Intent
Reduces chaotic dependencies between objects by making them communicate through a mediator object.
Problem
Form fields reference each other directly; changing one breaks five others.
Solution
Components notify a mediator, which decides who reacts.
Real-world analogy
Think of it like this
Air traffic control: pilots talk to the tower, not to each other.
Structure
Hover or tap a numbered role to highlight it in the diagram.
- 1ComponentA — Components hold business logic and a reference to the mediator, never to each other.
- 2Mediator — Mediator declares how components report events.
- 3ConcreteMediator — Concrete Mediator encapsulates the relations between components and decides who reacts.
- 4ComponentB — Components don't know which other components exist, so each can be reused alone.
Code example
A Go code sample for Mediator is coming soon. Factory Method, Singleton, Decorator, Observer and Strategy already have code in all six languages.
Applicability
Use Mediator when classes are tightly coupled through many references.
Use Mediator when components can't be reused because they depend on too many others.
Pros and cons
Pros
- Reduced coupling
- Reusable components
Cons
- The mediator can grow into a god object
Relations with other patterns
Check yourself
Check yourself
Dialog widgets (checkbox, text field, button) must enable and disable each other without direct references.
Saved in this browser only. Part of Behavioral patterns (0/11).