Difference between revisions of "Bridge"

From CDOT Wiki
Jump to: navigation, search
(Introduction)
(Introduction)
Line 1: Line 1:
 
__TOC__
 
__TOC__
 
== Introduction ==
 
== Introduction ==
The '''Bridge pattern''' is intended to decouple an abstraction from its implementation so both can vary independently. For example, a significant maintenance headache entails the coupling that occurs between custom classes and the class libraries they use. Bridges are useful for minimizing this coupling by providing an abstract description of the class libraries to the client.  The Bridge pattern is also know as Handle/Body.
+
The '''Bridge pattern''' is intended to decouple an abstraction from its implementation so both can vary independently.  The Bridge pattern is also know as Handle/Body.
  
 
== UML Structure ==
 
== UML Structure ==

Revision as of 19:26, 1 March 2007

Introduction

The Bridge pattern is intended to decouple an abstraction from its implementation so both can vary independently. The Bridge pattern is also know as Handle/Body.

UML Structure

Here is an example of the Bridge pattern.
Bridge.gif
Source: Downloaded from http://www.dofactory.com/Patterns/PatternBridge.aspx

Here is another example of the Bridge pattern where it decouples the abstraction from its implementation so that the two can vary independently Gof7.jpg
Source: Downloaded from http://home.earthlink.net/~huston2/dp/all_uml.html

Applicability

The Bridge pattern is applicable when:

  • we want to avoid a permanent binding between an abstraction and its implementation
  • both the abstractions and their implementations should be extensible by subclassing
  • changes in the implementation of an abstraction should have no impact on clients
  • we want to hide the implementation of an abstraction completely from clients
  • we want to share an implementation among multiple objects, and this fact should be hiddent from the client

Participants

The classes and/or objects participating in this pattern are:

  • Abstraction
    • defines the abstraction's interface
    • maintains a reference to an object of type Implementor
  • Refined Abstraction
    • extends the interface defined by Abstraction.
  • Implementor
    • defines the interface for implementation classes. This interface does not have to correspond exactly to Abstraction's interface; in fact the two interfaces can be quite different. The Implementation interface provides only primitive operations, and Abstraction defines high-level operations based on these primitives.
  • Concrete Implementor
    • implements the Implementor interface and defines its concrete implementation.


Consequences

The Bridge pattern has the following consequence:

  • Decoupling interface and implementation - inheritance tightly couples an abstraction with an implementation at compile time. Bridge pattern can be used to avoid the binding between abstraction and implementation and to select implenetation at run time
  • Improved extensibility - extend the Abstraction and Implementor hierarchies independently
  • Hiding implementation detail from clients - shield clients from implentation details, like the sharing of implemntor objects and accompanying reference count merchanism
  • Interface and implementation can be varied independently - maintaining two different class hierarchies for interface and implementation entitles to vary one independent of the other
  • Lossely coupled client code - Abstraction separates the client code from the implementation
  • Reduction in the number of sub classes
  • Cleaner code and Reduction in executable size

Implementation

When applying the Bridge pattern, consider the following implementation issues:

  • Only one Implementor
  • Creating the right Implementor object
  • Sharing implementors
  • Using multiple inheritance

Code Examples

References