Hello dear friends. In this video, we will examine the mediator design pattern. So, let's begin. In object-oriented programming, programs often consist of many classes. Business logic and computation are distributed among these classes. However, as more classes are added to a program, especially during maintenance and/or re-factoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. 

Furthermore, it can become difficult to change the program since any change may affect code in several other classes. In object-oriented programming, we should always try to design the system in such a way that components are loosely coupled and reusable. This approach makes our codes easier to maintain and test. In real life however, we often need to deal with a complex set of dependent objects. This is when the mediator pattern may come in handy. Mediator design pattern is one of the important and widely used behavioral design patterns. Mediator enables decoupling of objects by introducing a layer in between so that the interaction between objects happen via the layer. If the objects interact with each other directly, the system components are tightly coupled with each other.

That means higher maintainability costs and it's not hard to extend. The mediator pattern focuses on providing a mediator between objects for communication and helps in implementing loose coupling between objects. Air traffic control is a great example of mediator pattern where the airport control room works as a mediator for communication between different flights. Mediator works as a router between objects and it can have its own logic to provide a way of communication. In software engineering, the mediator pattern defines an object that encapsulates how a set of objects interact. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. 

With the mediator pattern, communication between objects is encapsulated within a mediator object. Objects no longer communicate directly with each other but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby reducing coupling. Let's examine the design participants. Mediator defines the interface for communication between colleague objects. ConcreteMediator implements the mediator interface and coordinates communication between colleague objects. It's aware of all of the colleagues and their purposes with regards to inter-communication. Colleague defines the interface for communication with other colleagues through its mediator. ConcreteColleague implements the colleague interface and communicates with other colleagues through its mediator.

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 maintainability of the code by loose coupling. So, what are the advantages of using the mediator pattern? Mediator decouples the number of classes and simplifies object protocols. Mediator centralizes the control. The individual components become simpler and much easier to deal with because they don't need to pass messages to one another. The components don't need to contain logic to deal with their inter-communication and therefore they are more generic. So, I think that's enough for theory, let's create a project using the mediator pattern. Let's say for example, you're maintaining a network of computers in mesh topology. A mesh network is a network topology in which each node relays data for the network. All mesh nodes cooperate in the distribution of data in the network. If a new computer is added or an existing computer is removed, all of the computers in that network should know about these two events. So, now let's design this structure with a mediator. First, we need an interface, let's name it Mediator. Now we will add two methods called register and unregister.

These methods must take the colleague class as a parameter but we haven't defined it yet. So, for now I will add them. Done. Let's define colleague class as abstract. We need a mediator and a name parameter. In the constructor, we will use them. Okay, done. Now we will add it to string method for name. We have to add register and unregister to receive notifications as abstract classes. Get done. Now we can create our computers. Extends from colleague, first add mediator, now add constructor. Let's override receive notification methods. Now we will add network mediator. First, we have to add a colleague array list. Now we will define register and unregister methods.

Okay, done, let's now show how the structure works. First, we need a mediator from NetworkMediator. I want to define three computer colleagues. First, I will register all the computers. Now I want to register the second one. Okay, done, let's try. John is added to the network at first through a register event. No notifications to any other colleagues since John is the first one. When Daisy is added to the network, John is notified. Line one of output is rendered now.

When Nicole is added to the network, both John and Daisy have been notified. Line two and line three of output is rendered now. When Daisy left the network through unregistered event, both John and Nicole have been notified. Line four and line five of output is rendered now. Great. We have now finished the mediator design pattern. In the next video, we will look into the memento design pattern. So, I'll see you in the next video my friends.