The mediator pattern

In many cases, when we design and develop software applications, we encounter many scenarios where we have modules and objects that have to communicate with one another. The easiest approach would be to make them in such a way that they know each other and can send messages directly.

However, this might create a mess. If we imagine, for example, a communication app in which each client has to connect to another one, it doesn't make sense for a client to manage many connections. A better solution would be to connect to a central server and for the server to manage the communication between the clients. The client sends the message to the server and the server keeps the connection active to all the clients, and it can broadcast messages to all required recipients.

Another example is where a specialized class is required to mediate between different controls, such as buttons, dropdowns, and list controls, in a graphical interface. For example, the graphical controls in a GUI can hold a reference to each other in order to invoke their methods reciprocally. But obviously, this will create an extremely coupled code in which each control depends on all the others. A better approach would be to make the parent responsible for broadcasting messages to all the required controls when something needs to be done. When something modifies in a control, it will notify the window, which will check which controls need to be informed and then inform them.