Bridge
m |
|||
| Line 21: | Line 21: | ||
==See also== | ==See also== | ||
| − | [[Favour composition over inheritance]] | + | * [[Favour composition over inheritance]] |
| + | * [[State]] | ||
| + | * [[Strategy]] | ||
Revision as of 01:32, 8 October 2008
The Bridge design pattern is used to "decouple an abstraction from it's implementation so that the two can vary independently"
Contents |
UML Diagram
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.
