Hello, dear friends. In this video, we will examine the mediator design pattern. 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 code easier to maintain and test. In real life, however, we often need to deal with a complex set of dependent objects. This is when 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 happens via the layer. If the objects interact with each other directly, the system components are tightly coupled with each other that makes higher maintainability cost and not hard to extend.

Mediator pattern focuses on providing a mediator between objects for communication and help in implementing loose coupling between objects. Air traffic controller 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 is aware of all of the colleagues and their purposes with regards to intercommunication. 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 intercommunication and therefore are more generic. I think that's enough for theory. Let's create a project using the mediator pattern. Let's say, for example, you are maintaining a network of computers in mesh topology.

A mesh network is a network topology in which 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 other computers in that network should know about these two events. Now, let's design this structure with mediator. First, we need an interface. Let's name it Mediator. Now, we will need to 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 constructor, we will use them. Done. Now, we will add to a String method for name. We have to add register and unregister, receive notifications as abstract classes. Done. Now, we can create our computers. Extends from Colleague. Now, add constructor. Let's override receive notification methods. Now, we will add NetworkMediator.

First, we have to add a Colleague ArrayList. Now, we will define register and unregister methods. Done. Let's show that how this structure is working. First, we need a mediator from NetworkMediator. I want to define tree ComputerColleague. First, I will register all computers. Now, I want to unregister second one. Done. Let's try. John is added to network at first through 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 1 of output is rendered now. When Nicole is added to network, both John and Daisy have been notified. Line 2 and line 3 of output is rendered now. When Daisy left the network through unregister event, both John and Nicole have been notified. Line 4 and line 5 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. See you in the next video.