Bridge

Also known as Handle/Body

Pattern Properties

Type: Structural, Object

Level: Component

Purpose

To divide a complex component into two separate but related inheritance hierarchies: the functional abstraction and the internal implementation. This makes it easier to change either aspect of the component.

Introduction

If you want to develop a To Do list for the Personal Information Manager, you might want to have flexibility in how it's represented to the user—listed items like tasks or contacts with bullets, numbers, maybe hieroglyphs. Additionally, you might want to have some way to modify the basic list functionality, giving users the ability to choose between an unordered list, a sequential list or a prioritized list.

To support this feature in the software, develop a group of list classes, each of which would provide a specific way to display the list and organize its information. This solution quickly becomes impractical, however, since there are many combinations of ways to display a list, and ways to store the list information.

It is be better to separate the To Do list's representation from its underlying implementation. The Bridge pattern accomplishes this by defining two classes or interfaces that work together. For the PIM, these are List and ListImpl. The List represents display functionality, but delegates the actual storage of list items to its underlying implementation, the ListImpl class.

The benefit of this approach is apparent when you add capabilities to the basic behavior. To add characters or numbering, subclass List. To support features like grouping items sequentially, extend ListImpl. The beauty of this solution is that you can “mix and match” the classes, producing a much greater range of total functionality.

Applicability

Use Bridge when:

You want flexibility between the component’s abstraction and implementation, avoiding a static relationship between the two.

Any changes of the implementation should be invisible to clients.

You identify multiple component abstractions and implementations.

Subclassing is appropriate, but you want to manage the two aspects of the system separately.

Description

Complex elements in a system can sometimes vary in both their external functionality and their underlying implementation. In such cases, inheritance is an undesirable solution, since the number of classes you must create increases as a function of both these aspects. Two representations and implementations yield four classes to develop, while three representations and implementations result in nine classes (see Table 3-2).

In addition, inheritance ties a component into a static model, making it difficult to change in the future. Changing a component is particularly challenging since they tend to vary as a system is being developed and used. It would be preferable to create a dynamic way to vary both aspects of the component on an as-needed basis.

Enter the Bridge pattern. The Bridge solves the problem by decoupling the two aspects of the component. With two separate inheritance chains—one devoted to functionality, the other to implementation—it’s much easier to mix and match elements from each side. This provides greater overall flexibility at a lower coding cost.

103