Behavioral Design Pattern
Mediator Behavioral Design Pattern
Design patterns and need in Software Development:
Design Patterns:
1.Design pattern in a simple term: is a way to solve problems in different situations in the form of template or description.
2.A pattern is a recurring solution to a problem in a context.
3.Design Pattern by Christopher Alexander, A Pattern Language-
“Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem,
in such a way that you can use this solution a million times over, without ever doing it the same way twice.”
Gang of Four (GoF) design patterns:
1.Design patterns are a very powerful tool for software developers.
2.Patterns are used by developers for their specific designs to solve their problems.
Following are the 23 design patterns, also known as Gang of Four (GoF) design patterns:
Behavioral Design pattern in .NET:
1.In software engineering, to carrying out flexibility in communication among software objects by identifying common communication pattern
2.Behavioral Design Pattern AKA Chains of behavior
3.Advantages:
1.It simplifies the communication among software objects
2.It is the best possible way to communicate between the objects
3.To serve particular client in a particular amount of time by saving the number of resources.
Mediator Behavioral Design Pattern:
1.Intent:
1.To reduce chaotic dependencies between object, Mediator is the best behavioral design pattern
2.Direct communication among object can be restricted and collaboration between them only happens via mediator object.
2.Problem:
Suppose we have a dialog for creating and editing customer profiles.
It consists of various form controls such as text fields, checkboxes, buttons, etc.
Some of the form elements may interact with others. For Ex. to submit the form, the submit button that has to validate values of all fields before saving the data.
If we have this logic implemented directly inside the code of the form elements we can’t reuse these in other forms of the app.
3.Solution:
Through Mediator Pattern, components must collaborate indirectly by calling a special mediator object that redirects the calls to appropriate components. As a result, the components depend only on a single mediator class.
In our example with the profile editing form, the dialog class itself may act as the mediator. Most likely, the dialog class is already aware of all of its sub-elements, so you won’t even need to introduce new dependencies into this class.
The most significant change happens to the actual form elements. Let’s consider the submit button. Previously, each time a user clicked the button, it had to validate the values of all individual form elements. Now its single job is to notify the dialog about the click. Upon receiving this notification, the dialog itself performs the validations or passes the task to the individual elements.
Thus, instead of being tied to a dozen form elements, the button is only dependent on the dialog class.
4.Real World Ex.:
Pilots of aircraft that approach or depart the airport control area don’t communicate directly with each other. Instead, they speak to an air traffic controller, who sits in a tall tower somewhere near the airstrip. Without the air traffic controller, pilots would need to be aware of every plane in the vicinity of the airport, discussing landing priorities with a committee of dozens of other pilots. That would probably skyrocket the airplane crash statistics.
The tower doesn’t need to control the whole flight. It exists only to enforce constraints in the terminal area because the number of involved actors there might be overwhelming to a pilot.
5.Pseudocode:
For Ex. considering a general scenario, the person hosting the meeting would have to learn every language and find a way to simultaneously communicate with each other. This would be a very complex process. However, the Mediator pattern helps eliminate mutual dependencies between the different people on the call.
Although the different participants on the call seem to be communicating directly, they don’t. Instead, the participant only needs to check the captioning system to understand a message and then speak without knowledge of the words and their meanings used by the other attendees.
An element, triggered by a user, doesn’t communicate with other elements directly, even if it looks like it’s supposed to. Instead, the element only needs to let its mediator know about the event, passing any contextual info along with that notification.
// The mediator interface declares a method used by components to notify the mediator about various events.
interface Mediator is
method notify(sender: Component, language: string)
// The concrete mediator class.
class Chat implements Mediator is
private field message: string
private field speaker, listener: User
private field isLanguageAccepted: Checkbox
constructor Chat() is
// When something happens with a component, it notifies the mediator. Upon receiving a notification, the mediator may do something on its own or pass the request to another component.
method notify(sender, language) is
// if the language is filled into the system and can be translated, then it will inform the mediator regarding this and accordingly proceed with translation.
// Components communicate with a mediator using the mediator interface.
class Component is
field message: Mediator
constructor Component(message) is
this. message = message
method translate() is
// check the language to be translated and change the message based on the translated value
// Concrete components don't talk to each other. They have only one communication channel, which is sending notifications to the mediator. So our concrete components A and B (different people) share their message with each other after it getting translated using the mediator.
class User extends Component is
// ...
class Language extends Component is
// ...
class Checkbox extends Component is
// ...6.Pros and Cons:
1.Pros:
1.Single Responsibility Principle.
We can extract the communications between various components into a single place, making it easier to comprehend and maintain.
2.Open/Closed Principle.
We can introduce new mediators without having to change the actual components.
3.We can reduce coupling between various components of a program.
4.We can reuse individual components more easily.
2.Cons:
Over time a mediator can evolve into a God Object( is an object that references a large number of distinct types, has too many unrelated or uncategorized methods, or some combination of both. )
