One of the goals of object-oriented design is to distribute behavior among different objects which encourages reuse. But with larger software the interactions between these objects become more and more complex and we have a situation where each object knows each other. This might end up in a huge monolithic application where the change of one behavior affects a large number of objects which must be adapted too. So the target reuse is reduced by the growth of references.

GUIs usually represent such systems and suffer from an increasing connection complexity with lots of components. They consist of different widgets which interact with each other and share distributed behavior. A selection in a listbox might affect what is displayed in an textfield or how this is displayed in coherence with another widget. So the listbox must know the textfield and possible connected widgets.

The solution might be the use of the Mediator Pattern. This pattern helps to model a class which is responsible for controlling and coordinating the interactions of a group of other objects. It helps encapsulate collective behavior in a separate mediator object. The Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and allowing the designer to vary their interaction independently. Objects don’t need to know about each other, they just need to know their Mediator.

This is perfect for GUIs where the single widgets can handle their own behavior and the relation to its colleagues is swaped out to the mediator object. The widgets might be reused in different situations and applications while the controller is a specific implementation.

GUIs use mostly components the language basicaly provides. There are two possible ways to integrate these components in the pattern. One is to extend the basic component with the widget (see Java example). The widget can then be used as the normal component would be.
Another apporach is to wrap the widget around the component (see ActionScript example). The widget then must provide a method to provide access on the component.

There are different types of implementation methods for this pattern. One is to use an additional Observer Pattern to manage the communication between mediator and widgets.
Another one defines specific communication channels that allow the widget to provide additional data depending on its inner state.
A third solution uses a delegation model where the widget passes itself as an argument allowing the mediator to decide what to do. The selection of the proper solution depends on the balance between reuse and ellegant communication of the widgets.

Donload the Mediator Pattern Java / ActionScript.