+972 52-548-6969
Design patterns in the test of timeBridge
The bridge pattern is a design pattern used in software engineering which is meant to "decouple an abstraction from its implementation so that the two can vary independently".The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.
Bridge is quite complex, mostly because it is composed of Abstraction, Refined Abstraction, Implementor and Concrete Implementor. Here is a concrete example (pun intended):
- Abstraction: CImage
- Refined Abstraction: CBmpImage, CJpegImage
- Implementor: CimageImp
- Concrete Implementor: CWinImp, COS2Imp
In general, I don’t like complex things, and of the top of my head, I can’t think of a time when I used this approach. Until such time when I can see a really good reason why I would want to do something like this, I see very little reason to bother.
Recommendation: Avoid, there are simpler options to solving those sort of problems.
More posts in "Design patterns in the test of time" series:
- (21 Jan 2013) Mediator
- (18 Jan 2013) Iterator
- (17 Jan 2013) Interpreter
- (21 Nov 2012) Command, Redux
- (19 Nov 2012) Command
- (16 Nov 2012) Chain of responsibility
- (15 Nov 2012) Proxy
- (14 Nov 2012) Flyweight
- (09 Nov 2012) Façade
- (07 Nov 2012) Decorator
- (05 Nov 2012) Composite
- (02 Nov 2012) Bridge
- (01 Nov 2012) Adapter
- (31 Oct 2012) Singleton
- (29 Oct 2012) Prototype
- (26 Oct 2012) Factory Method
- (25 Oct 2012) Builder
- (24 Oct 2012) A modern alternative to Abstract Factory–filtered dependencies
- (23 Oct 2012) Abstract Factory
Comments
You actually see this quite a lot - only what's shown here on the CImage side all have I prefixes (in .NET) i.e. they are all interfaces...
The bridge pattern come to solve problems that ioc/di solves, the bridge is the oldest way.
I've seen this pattern used only used once or twice explicitly; that is, being named "Bridge". However, this pattern -like most others frankly- grow into existence somehow, particularly when you're really set for decoupling two bodies of code.
I regularly have a model project (which I can understand) implemented by a specific technology (which I don't, but with some gOOgling fiddle out in the end). I don't want the difficult technology ruin my simple view of the world (that is, I don't want technology X mess up my model). I think most who are fully dedicated to their models won't let their implementation leak into their model. Henceforth, the Bridge is created; even though the programmer has no idea what is actually is. That is why you hardly ever see it in the real world; it is often decoupled so much you don't even notice.
As the occasional publisher of APIs, I have used and abused the bridge pattern over and over and over. I've used it more in C++ than in .NET, but it can be useful there, too, at times.
Your example is somehow wrong. Actually the only Interface here is the one called CImageImp. Why does it have the Imp suffix then? Actually the CImageImp makes me think that it's an implementation of the CImage (which is not obviously not true given the uml notation you used). Then CImage cannot be a pure interface (as somebody suggests here) as it "has" a CImageImp. The quality of the wikipedia article you linked here is much better, I'd say that you read it once again and refine yours.
Comment preview