Bridge
JaninaVoigt (Talk | contribs) |
|||
| 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". |
| − | == | + | ==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
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
| Design patterns | |
|---|---|
|
Creational: Abstract Factory | Builder | Factory Method | Prototype | Singleton | |
