Mediator Pattern
Mediator: start from the problem
See the responsibilities
Several interface widgets update one another: selecting a shipping method changes available times and enables checkout. Direct links between every pair become difficult to change.
This is a behavioral pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Mediator addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Mediator centralizes a set of interactions so participants communicate through a coordination object. Participants still own their local responsibilities; the mediator owns the interaction rules. This can replace a dense network of pairwise dependencies.
Our local shipping mediator changes checkout readiness after a shipping choice. It keeps the interaction in one place without requiring the shipping widget to know the checkout widget’s implementation.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
const checkout = {enabled: false};
const mediator = {
shippingSelected(method) { checkout.enabled = method === 'pickup' || method === 'courier'; }
};
mediator.shippingSelected('pickup');
console.log(checkout.enabled);
mediator.shippingSelected('unknown');
console.log(checkout.enabled);Expected output
true
falseChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it when a defined group has complicated interaction rules and pairwise dependencies obscure the flow. Keep each coordination boundary cohesive.
A mediator can become a giant object controlling unrelated behaviour. A remote coordinator has availability and durable-progress obligations absent from this local example. Centralizing interaction does not make every participant’s state change atomic.
Distinguish the neighbouring patterns
Observer announces changes to subscribers. Mediator controls how participants interact. Saga orchestration is a distributed workflow with durable recovery, not simply a local mediator renamed.
Follow notification relationships, durable workflow orchestration, cohesive service responsibilities to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Mediator, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside cohesive service responsibilities.
Reaching the recap and completing the quizzes are separate milestones.