Bridge (Pattern)

<<Back to Patterns

The Bridge pattern of this page is based on the book Design Patterns: Elements of Reusable Object-Oriented Software .

Intent

Decouple an abstraction from its implementation so that the two can vary independently.

Motivation

The Bridge problem

When an abstraction can have one of several possible implementations, the usual way to accommodate them is to use inheritance.
An abstract class defines the interface to the abstraction, and concrete subclasses implement it in different ways.
But this approach isn't always flexible enough.
Inheritance binds an implementation to the abstraction permanently, which makes it difficult to modify, extend, and reuse abstractions and implementations independently.

Consider the implementation of a portable Window abstraction in a user interface toolkit.
This abstraction should enable us to write applications that work on both the X Window System and IBM's Presentation Manager (PM), for example.
Using inheritance, we could define an abstract class Window and subclasses XWindow and PMWindow that implement the Window interface for the different platforms.
But this approach has two drawbacks:

1. It's inconvenient to extend the Window abstraction to cover different kinds of windows or new platforms.
   Imagine an IconWindow subclass of Window that specializes the Window abstraction for icons.
   To support IconWindows for both platforms, we have to implement two new classes, XIconWindow and PMIconWindow.
   Worse, we'll have to define two classes for every kind of window.
   Supporting a third platform requires yet another new Window subclass for every kind of window.
2. It makes client code platform-dependent.
   Whenever a client creates a window, it instantiates a concrete class that has a specific implementation.
   For example, creating an XWindow object binds the Window abstraction to the X Window implementation, which makes the client code dependent on the X Window implementation.
   This, in turn, makes it harder to port the client code to other platforms.

Clients should be able to create a window without committing to a concrete implementation.
Only the window implementation should depend on the platform on which the application runs.
Therefore client code should instantiate windows without mentioning specific platforms.

Applicability

Structure

Use the Bridge pattern when

• You want to avoid a permanent binding between an abstraction and its implementation.
  This might be the case, for example, when the implementation must be selected or switched at run-time.
• Both the abstractions and their implementations should be extensible by subclassing.
  In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently.
• Changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled.
• (C++) You want to hide the implementation of an abstraction completely from clients. In C++ the representation of a class is visible in the class interface.
• You have a proliferation of classes as shown earlier in the first Motivation diagram. Such a class hierarchy indicates the need for splitting an object into two parts. Rumbaugh uses the term "nested generalizations" [RBP+91] to refer to such class hierarchies.
• You want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client. A simple example is Coplien's String class [Cop92], in which multiple objects can share the same string representation (StringRep).

Participants

• Abstraction (Window)
  • Defines the abstraction's interface.
  • Maintains a reference to an object of type Implementor.
• RefinedAbstraction (IconWindow)
  • Extends the interface defined by Abstraction.
• Implementor (WindowImp)
  • Defines the interface for implementation classes. This interface doesn't have to correspond exactly to Abstraction's interface; in fact the two interfaces can be quite different. Typically the Implementor interface provides only primitive operations, and Abstraction defines higher-level operations based on these primitives.
• ConcreteImplementor (XWindowImp, PMWindowImp)
  • Implements the Implementor interface and defines its concrete implementation.

Collaborations

Abstraction forwards client requests to its Implementor object.

Consequences

The Bridge pattern has the following consequences:

• Decoupling interface and implementation. An implementation is not bound permanently to an interface. The implementation of an abstraction can be configured at run-time. It's even possible for an object to change its implementation at run-time.
  Decoupling Abstraction and Implementor also eliminates compile-time dependencies on the implementation. Changing an implementation class doesn't require recompiling the Abstraction class and its clients. This property is essential when you must ensure binary compatibility between different versions of a class library.
  Furthermore, this decoupling encourages layering that can lead to a better-structured system. The high-level part of a system only has to know about Abstraction and Implementor.
• Improved extensibility. You can extend the Abstraction and Implementor hierarchies independently.
• Hiding implementation details from clients. You can shield clients from implementation details, like the sharing of implementor objects and the accompanying reference count mechanism (if any).

Related Patterns

An Abstract Factory can create and configure a particular Bridge.
The Adapter pattern is geared toward making unrelated classes work together. It is usually applied to systems after they're designed. Bridge, on the other hand, is used up-front in a design to let abstractions and implementations vary independently.

• Composite
• Adapter

Example implementation

The example code is created in Java. The code requires the installation of Java Developer and Ant.

• Java code will be coming soon.