Bridge

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
 
[[Category:Design Patterns]]
 
[[Category:Design Patterns]]
 
[[Category:Structural Patterns]]
 
[[Category:Structural Patterns]]
The Bridge design pattern is used to "decouple an abstraction from it's implementation so that the two can vary independently"
+
The Bridge design pattern is used to "decouple an abstraction from it's implementation so that the two can vary independently".
  
==UML Diagram==
+
==Structure==
  
 
[[Image:Bridge.jpg]]
 
[[Image:Bridge.jpg]]
Line 21: Line 21:
  
 
When the abstraction and implementation of drawing a shape are separated, they can vary independently. There are many types of shapes, such as circles, triangles and rectangulars, each with its own properties. There is one thing all shapes do and that's drawing themselves. However, drawing shapes (graphics) to a screen can sometimes be dependent on different graphics implementations. For example in Java you have two different Graphics APIs, Swing and AWT. So you want to be able to draw your shape with both APIs but you don't want each shape to implement each API or modify them so they are able to use different APIs is quite impractical. That's where the bridge pattern comes into play. The bridge pattern helps by allowing the creation of new implementation classes that provide the drawing implementation. The abstraction class, shape, provides methods for getting the size or properties of a shape. The implementation class, drawing, provides an interface for drawing shapes (graphics). If a new shape needs to be created or there is a new graphics API to be drawn on, then it is very easy to add a new implementation class that implements the needed features.
 
When the abstraction and implementation of drawing a shape are separated, they can vary independently. There are many types of shapes, such as circles, triangles and rectangulars, each with its own properties. There is one thing all shapes do and that's drawing themselves. However, drawing shapes (graphics) to a screen can sometimes be dependent on different graphics implementations. For example in Java you have two different Graphics APIs, Swing and AWT. So you want to be able to draw your shape with both APIs but you don't want each shape to implement each API or modify them so they are able to use different APIs is quite impractical. That's where the bridge pattern comes into play. The bridge pattern helps by allowing the creation of new implementation classes that provide the drawing implementation. The abstraction class, shape, provides methods for getting the size or properties of a shape. The implementation class, drawing, provides an interface for drawing shapes (graphics). If a new shape needs to be created or there is a new graphics API to be drawn on, then it is very easy to add a new implementation class that implements the needed features.
 +
 +
TODO: add UML diagram
 +
 +
==Use When==
 +
You should use the Bridge pattern when:
 +
* you don't want to bind an abstraction to its implementation, for example because you want to be able to switch the implementation at runtime.
 +
* you may extend both the abstraction and the implementation through subclassing and you want to be able to combine the different abstractions and implementations independently.
 +
* changes in the implementation should not affect clients and force them to be recompiled.
 +
* you have too many classes in a class hierarchy and want to split it into two.
 +
* you want to share an implementation between several objects without clients knowing about it.
  
 
==See also==
 
==See also==

Revision as of 06:52, 24 July 2009

The Bridge design pattern is used to "decouple an abstraction from it's implementation so that the two can vary independently".

Contents

Structure

Bridge.jpg

Participating Classes

Abstraction

  • defines the abstract interface
  • maintains the Implementor reference

Refined Abstraction

  • extends the interface defined by Abstraction

Implementor

  • defines the interface for implementation classes

ConcreteImplementor

  • implements the Implementor interface

Example: Shape abstraction

When the abstraction and implementation of drawing a shape are separated, they can vary independently. There are many types of shapes, such as circles, triangles and rectangulars, each with its own properties. There is one thing all shapes do and that's drawing themselves. However, drawing shapes (graphics) to a screen can sometimes be dependent on different graphics implementations. For example in Java you have two different Graphics APIs, Swing and AWT. So you want to be able to draw your shape with both APIs but you don't want each shape to implement each API or modify them so they are able to use different APIs is quite impractical. That's where the bridge pattern comes into play. The bridge pattern helps by allowing the creation of new implementation classes that provide the drawing implementation. The abstraction class, shape, provides methods for getting the size or properties of a shape. The implementation class, drawing, provides an interface for drawing shapes (graphics). If a new shape needs to be created or there is a new graphics API to be drawn on, then it is very easy to add a new implementation class that implements the needed features.

TODO: add UML diagram

Use When

You should use the Bridge pattern when:

  • you don't want to bind an abstraction to its implementation, for example because you want to be able to switch the implementation at runtime.
  • you may extend both the abstraction and the implementation through subclassing and you want to be able to combine the different abstractions and implementations independently.
  • changes in the implementation should not affect clients and force them to be recompiled.
  • you have too many classes in a class hierarchy and want to split it into two.
  • you want to share an implementation between several objects without clients knowing about it.

See also


Personal tools