Structural Patterns - Applied Java Patterns - page 93

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.