Also known as:
Intermediary, Controller
-
Simplifiescommunication between multiple objects in a system by centralizing their interactions through a mediator.- Instead of objects interacting directly,
- they communicate via a mediator,
- reducing dependencies and making the system easier to manage.
-
- The pattern restricts direct communications between the objects and forces them to collaborate only via a mediator object.
- lets you reduce chaotic dependencies between objects.
- Mediator Design Pattern
-
- Mediator pattern is used to reduce communication complexity between multiple objects or classes. - This pattern provides a mediator class - which normally handles all the communications between different classes - and supports easy maintenance of the code by loose coupling. - Mediator pattern falls under behavioral pattern category. -
The Mediator pattern: - one of the important and widely used behavioral design patterns. - Mediator enables the decoupling of objects by introducing a layer in between - so that the interaction between objects happens via the layer. - Real Life: - If the objects interact with each other directly, the system components are tightly coupled with each other making higher maintainability cost and not hard to extend. - The mediator pattern focuses on providing a mediator between objects for communication and helps in implementing loose coupling between objects.
- Various classes that contain some business logic.
- Each component has a reference to a mediator, declared with the type of the mediator interface.
- The component isn’t aware of the actual class of the mediator, so you can reuse the component in other programs by linking it to a different mediator.
- declares methods of communication with components, which usually include just a single notification method.
- Components may pass any context as arguments of this method, including their own objects, but only in such a way that no coupling occurs between a receiving component and the sender’s class.
- encapsulate relations between various components.
- Concrete mediators often keep references to all components they manage and sometimes even manage their lifecycle.
Components must not be aware of other components. If something important happens within or to a component, it must only notify the mediator. When the mediator receives the notification, it can easily identify the sender, which might be just enough to decide what component should be triggered in return.
From a component’s perspective, it all looks like a total black box. The sender doesn’t know who’ll end up handling its request, and the receiver doesn’t know who sent the request in the first place.
-
Mediator
- The Mediator interface
defines the communication contract,- specifying methods that concrete mediators should implement to facilitate interactions among colleagues..
- It encapsulates the logic for coordinating and managing the interactions between these objects,
- promoting loose coupling and centralizing control over their communication.
- The Mediator interface
-
Colleague
- Colleague classes are
the components or objects that interact with each other. They communicate through the Mediator, andeach colleague class is only aware of the mediator, not the other colleagues.- This isolation ensures that changes in one colleague do not directly affect others.
- Colleague classes are
-
Concrete Mediator
- is a specific implementation of the Mediator interface.
- It coordinates the communication between concrete colleague objects, handling their interactions and ensuring a well-organized collaboration while keeping them decoupled.
-
Concrete colleague
- Concrete Colleague classes are the specific implementations of the Colleague interface.
- They rely on the Mediator to communicate with other colleagues, avoiding direct dependencies and promoting a more flexible and maintainable system architecture.
-
Use the Mediator pattern
- when it’s hard to change some of the classes because they are tightly coupled to a bunch of other classes.
-
Use the Mediator pattern
- when you can’t reuse a component in a different program because it’s too dependent on other components.
-
Use the Mediator pattern
- when you find yourself creating tons of component subclasses just to reuse some basic behavior in various contexts.
- Several airplanes in an airport must coordinate their movements and communicate with one another in order to prevent collisions and guarantee safe takeoffs and landings.
- Direct communication between aircraft without a centralized mechanism could result in chaos and higher risk.
- Air Traffic Complexity:
- Direct communication between airplanes might result in complex and error-prone coordination, especially when dealing with multiple aircraft in the same airspace.
- Collision Risks:
- Without a centralized control mechanism, the risk of collisions between airplanes during takeoffs, landings, or mid-flight maneuvers increases.
-
By managing the complex coordination and communication between aircraft and air traffic controllers,
-
the mediator pattern contributes to a safer and better-organized aviation system.
-
Centralized Control: By serving as a mediator, the air traffic control tower helps aircraft communicate with one another.
-
This guarantees that every aircraft is aware of the location and intentions of every other aircraft.
-
Collision Avoidance: The mediator (air traffic control tower) manages the flow of airplanes, preventing collisions by providing clear instructions and coordinating their movements.
/// 1. Colleague Interface(Airplane)
/// Colleague Interface
abstract interface class Airplane {
void requestTakeoff();
void requestLanding();
void notifyAirTrafficControl(String message);
}
/// 2. Concrete Colleague Class(CommercialAirplane)
class CommercialAirplane implements Airplane {
final AirTrafficControlTower _mediator;
CommercialAirplane(AirTrafficControlTower mediator) : _mediator = mediator;
@override
void requestTakeoff() => _mediator.requestTakeoff(this);
@override
void requestLanding() => _mediator.requestLanding(this);
@override
void notifyAirTrafficControl(String message) =>
print("Commercial Airplane: $message");
}
/// 3. Mediator Interface(AirTrafficControlTower)
abstract interface class AirTrafficControlTower {
void requestTakeoff(Airplane airplane);
void requestLanding(Airplane airplane);
}
/// 4. Concrete Mediator Class(AirportControlTower)
class AirportControlTower implements AirTrafficControlTower {
@override
void requestTakeoff(Airplane airplane) {
// Logic for coordinating takeoff
airplane.notifyAirTrafficControl("Requesting takeoff clearance.");
}
@override
void requestLanding(Airplane airplane) {
// Logic for coordinating landing
airplane.notifyAirTrafficControl("Requesting landing clearance.");
}
}
// main
void main(args) {
// Instantiate the Mediator (Airport Control Tower)
AirTrafficControlTower controlTower = AirportControlTower();
// Instantiate Concrete Colleagues (Commercial Airplanes)
Airplane airplane1 = CommercialAirplane(controlTower);
Airplane airplane2 = CommercialAirplane(controlTower);
// Set up the association between Concrete Colleagues and the Mediator
airplane1.requestTakeoff();
airplane2.requestLanding();
// Output:
// Commercial Airplane: Requesting takeoff clearance.
// Commercial Airplane: Requesting landing clearance.
}
// Commercial Airplane: Requesting takeoff clearance.
// Commercial Airplane: Requesting landing clearance.
- Your system involves a set of objects that need to communicate with each other in a complex manner, and you want to avoid direct dependencies between them.
- You want to promote loose coupling between objects, allowing them to interact without knowing the details of each other's implementations.
- You need a centralized mechanism to coordinate and control the interactions between objects, ensuring a more organized and maintainable system.
- You anticipate changes in the behavior of components, and you want to encapsulate these changes within the mediator, preventing widespread modifications.
- You want to reuse individual components in different contexts without altering their internal logic or communication patterns.
- The interactions between components are straightforward, and introducing a mediator would add unnecessary complexity.
- The Single Responsibility Principle states that each component has a single responsibility; adding a mediator could go against this principle and result in less maintainable code.
- Introducing a mediator could introduce a performance overhead, especially in situations where direct communication between components is more efficient.
- In small-scale applications with a limited number of components, the overhead of implementing a mediator might outweigh its benefits.
- If the Mediator pattern appears like an over-engineered answer for your system's particular requirements, don't use it. Always take into account the particular requirements of your application as well as the trade-offs.
- The main idea of the Mediator pattern is to extract the traversal behavior of a collection into a separate object called an
mediator.