The fundamental idea of the Mediator pattern is that one central Mediator object manages all connections between different objects.
Mediator pattern with 4 Front End objects and 5 Back End Objects.
In this diagram, I have represented the colleagues talking through the Mediator into frontend and backend objects. Generally, the front end would be the graphical user interface components like buttons and text boxes, and the back end would be the actual data model.
This is a common use of the Mediator pattern. This structure is more vague than most of the other patterns you have seen. There is no superclass-subclass structure and the number of objects mediated may change.
Each object probably has a reference or pointer to the Mediator, but the Mediator may or may not have specific references to each of the objects. A change in a frontend object may not affect the back end. For instance, in a word processor, a change in the scroll bar may result in a corresponding change in the document view, but no change at all to the data structure for the text stored in the back end.
Mediator Pattern: The Problem
Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
The problem that commonly occurs in dialog boxes
If each object in the dialog takes responsibility for the dependencies it is associated with, the result is a highly coupled set of objects with low cohesion.
Mediator Relationship
Prior to the use of a mediator there is a complex relationship between all of the classes
The mediator disconnects the classes and presents a single target interface or set of targets