Skip to content
Design Patterns

Mediator

Purpose

The Mediator pattern is a behavioral design pattern that aims to reduce direct dependencies between components or objects in a system. It promotes loose coupling by centralizing communication between objects through a mediator object, instead of allowing them to communicate directly with each other. By doing so, it enhances the maintainability and extensibility of the system.

Context

In complex systems, when multiple components need to interact with each other, direct communication can lead to tight coupling, making the code difficult to maintain and modify. The Mediator pattern comes into play when we want to decouple these components and allow them to interact in a more organized and coordinated manner.

Participants

  1. Mediator: This interface or class defines the communication protocol that the components should follow. It declares methods to facilitate communication between the components.
  2. ConcreteMediator: This is the concrete implementation of the Mediator interface. It encapsulates the logic for coordinating the communication between the components.
  3. Colleague: These are the components or objects that need to interact with each other but want to avoid direct coupling.
  4. ConcreteColleague: Each Colleague communicates with the Mediator through this concrete implementation. It follows the communication protocol defined by the Mediator.

Flow

  1. Components that need to communicate with each other refer to the Mediator interface.
  2. Each component registers itself with the Mediator when it is created or initialized.
  3. When a component needs to communicate with another component, it does not send messages or make direct calls. Instead, it sends a request to the Mediator using the defined protocol.
  4. The Mediator receives the request and knows which Colleague should handle it.
  5. The Mediator forwards the request to the appropriate ConcreteColleague.
  6. The ConcreteColleague processes the request and may send a response back through the Mediator if necessary.
  7. The Mediator then routes the response to the appropriate recipient.
  8. Components can interact with each other indirectly through the Mediator, without having to know about each other’s existence.

Real World Scenarios

  1. Collaborative Code Review: Developers review and provide feedback on each other’s code changes using a code review tool or platform.
  2. Message Queue: Microservices communicate asynchronously by sending messages through a message broker to avoid direct coupling.
  3. Chat Application: Users exchange messages through a central server acting as a mediator to facilitate real-time communication.
  4. Event Handling: A GUI framework uses the observer pattern where UI components (observers) respond to events triggered by user interactions (subjects).
  5. Dependency Injection: Components receive their dependencies from a central container (mediator) to promote loose coupling and easy testing.
  6. MVC Architecture: Model, View, and Controller components interact through a mediator to handle user input and update the UI.
  7. Flight Booking System: Various system components (booking, payment, inventory) interact through a mediator for flight reservation and management.
  8. Version Control System: Developers interact with a central repository (mediator) to manage code versions and resolve conflicts.
  9. Automated Build System: Build tasks and tools are orchestrated through a build server (mediator) to produce software artifacts.
  10. Online Marketplace: Buyers and sellers communicate through a central platform (mediator) to initiate and complete transactions.

Mnemonic

“Mediating Meetup”

Explanation:

“Mediating”: Represents the Mediator pattern, acting as the host or mediator that facilitates communication between different components (Colleagues) in the system, just like a meetup organizer coordinating interactions.

“Meetup”: Denotes the gathering of ConcreteColleagues, invited by the ConcreteMediator, to collaborate and exchange information without direct dependencies.

Imagine a “Mediating Meetup” where the Mediator pattern acts as the event organizer, responsible for bringing together various components (Colleagues) from different parts of the system to join the meetup. Each component communicates with others through the mediator, but they are loosely coupled, enjoying the benefits of the Mediator pattern. The meetup encourages efficient collaboration and reduces complexity, making the event a successful and harmonious occasion in the software development world.