Lesson 12	Mediator: consequences
Objective	Describe the Benefits and Pitfalls of the Mediator Pattern.

Describe Benefits and Pitfalls of the Mediator Pattern

The Mediator pattern is a design pattern that decouples interacting objects by providing a single object that manages their interactions. This pattern is often used to simplify complex systems by reducing the number of direct dependencies between objects. Here are some of the advantages of the Mediator pattern:

Decoupling: The Mediator pattern decouples interacting objects by providing a single object that manages their interactions. This makes the system easier to understand and maintain, as changes to one object do not require changes to other objects.
Reusability: The Mediator pattern can make objects more reusable, as they do not need to know about the specific details of other objects. This makes it easier to add new objects to the system, as they only need to know how to interact with the Mediator.
Centralization: The Mediator pattern can centralize control of the system, making it easier to manage and troubleshoot. This is because the Mediator object is responsible for coordinating the interactions between all other objects.

Here are some of the disadvantages of the Mediator pattern:

Complexity: The Mediator pattern can introduce complexity into the system, as it requires a new object to be created and managed. This can make the system more difficult to understand and maintain.
Single point of failure: The Mediator object is a single point of failure in the system. If the Mediator object fails, then all other objects in the system will fail as well.
Coupling:The Mediator pattern can introduce coupling between objects, as they all need to know about the Mediator object. This can make it difficult to add new objects to the system, as they will need to be updated to know about the Mediator object.

Overall, the Mediator pattern can be a useful design pattern for decoupling interacting objects and simplifying complex systems. However, it is important to weigh the advantages and disadvantages of the pattern before using it in a particular system. In your case, as a system's architect for a Fortune 500 company, you would need to carefully consider the specific needs of your system before deciding whether or not to use the Mediator pattern. If you are concerned about the complexity or single point of failure of the pattern, then you may want to consider other design patterns. However, if you need to decouple interacting objects and simplify your system, then the Mediator pattern may be a good option for you.

Decoupling Process

I have emphasized the simplicity gained by the Mediator pattern. However, there is a second big advantage which is decoupling^[1]. The decoupling process allows senders and requesters to be changed independently from each other. You can replace one object in the structure with a different object without affecting the classes. You can add multiple objects to the structure.
The Mediator pattern enables you to plug in and pull out components with ease. Another advantage is that subclassing is reduced. Since the Mediator becomes responsible for changes needed in the system, you only need to derive from the Mediator to handle a new system.
You generally do not need to subclass to support new connections. There is one significant disadvantage to this pattern. Since the Mediator itself often needs to be very intimate with all the different classes, it can become extremely complex. This can make it difficult to maintain.

In order to have good object oriented design we have to create classes interacting one with each other. If certain principles are not applied the final framework will end in chaos where each object relies on many other objects in order to run. In order to avoid tightly coupled frameworks, we need a mechanism to facilitate the interaction between objects in such a way that objects are not aware of the existence of other objects. Let's take the example of a screen. When we create the screen we add controls to the screen. This control needs to interact with all the other control. For example when a button is pressed, it must know if the data is valid in other controls. As you have seen if you created different applications using forms you don't have to modify each control class each time you add a new control to the form. All the operations between controls are managed by the form class itself. This class is called mediator.

Advantages of the Mediator Pattern

Orchestrated Harmony: Just as a conductor harmonizes the various instruments in an orchestra, the Mediator Pattern brings order and coordination among disparate objects in a system. It centralizes external communications, which allows objects to remain ignorant of the complex relationships they are a part of, ensuring that each object plays its part seamlessly.
Reduced Object Dependencies: Imagine a social gathering where everyone converses only through a single host. The Mediator acts as that host, reducing the need for every object to directly interact with every other object. This isolation allows one to be altered, added, or removed without necessitating changes in others, making the ensemble highly modular and easier to manage.
Enhanced Object Reusability: Objects in a Mediator Pattern become akin to solo performers able to play in multiple orchestras. Because they are decoupled from the system they serve, they can be reused in different contexts with little to no modification, much like a versatile actor taking on various roles yet keeping the essence of their craft intact.
Simplified Maintenance and Lowered Complexity: The Mediator acts as a gatekeeper or a hub, making it easier to understand and manage the system's overall behavior. Like a well-designed traffic intersection reduces road accidents, the Mediator simplifies the path of communication, making it easier to navigate the complex web of object interactions during maintenance.

Disadvantages of the Mediator Pattern

Centralization of Control: The Mediator becomes the omnipotent director of the show, and if it fails, the entire system grinds to a halt. This single point of control can be both a bottleneck for performance and a single point of failure, much like how a conductor’s misstep could throw the entire orchestra out of sync.
Complexity of the Mediator: The Mediator, in its quest to simplify relationships among objects, can become an epitome of complexity itself. Imagine a diplomat entangled in the political intricacies of multiple nations; the Mediator similarly risks becoming overly complex as it takes on more responsibilities, making it harder to maintain.
Potential for Feature Envy: In some cases, the Mediator might need to access too much information about the objects it's coordinating, resembling a gossip monger who knows too much about everyone. This can lead to a situation called 'Feature Envy,' where the Mediator is too involved in the affairs of other classes, leading to potential issues in encapsulation.
Risk of Monolithism: While the Mediator aims to bring harmony, it can unintentionally turn into a monolithic entity that is resistant to change. Much like a rigid bureaucracy that becomes an obstacle rather than a facilitator, a poorly designed Mediator can stifle the very flexibility and modularity it aims to bring.

In summary, the Mediator Pattern, like a skillful maestro, can bring out the best in a system by enhancing modularity and simplifying interactions. Yet, it carries the risk of becoming a complicated or overbearing figure that may create more problems than it solves. Therefore, it requires careful orchestration to yield its benefits while minimizing its drawbacks.

[1]decoupling: Coupling describes the degree of dependency between one entity to another entity. Often classes or objects.