Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from refering to each other explicitly, and it lets you vary their interactions independently.
The Mediator design pattern is often implented by using the Observer design pattern. A ConcreteMediator registers itself as an Observer:Observer; each ConcreteColleague is an Observer:Subject. When the Observer pattern is used the colleagues do not have to know their mediator.
If the programming language, like Java, supports anonymous classes then the Mediator can just create responder objects and register them with the Collegue objects. This is how most Java GUI application classes work. An application class contains the main() method and its helper methods. These methods create listeners that are registered with the various GUI components.
In this kind of application organization, the Mediator (the application class) is not directly involved in communication between components. It only sets up the communication channels and the responses. It is not clear if GHJV would consider this as a variant of the Mediator design pattern but it certainly satisfies the intent, and in some ways is better.