Possible Duplicate:
Understanding the bridge design pattern
I have read lots of material about the bridge design pattern:
- http://www.codeproject.com/Articles/3151/Illustrated-GOF-Design-Patterns-in-C-Part-II-Struc
- http://sourcemaking.com/design_patterns/bridge
- http://en.wikipedia.org/wiki/Bridge_pattern
- Understanding the bridge design pattern
- Why would a programmer want to separate implementation from interface?
And I have to say that I am still confused. On the one hand the pattern is described as "decouple an abstraction from its implementation so that the two can vary independently" by GOF. But isn't this the job done by interfaces?
Let's take the example from wikipedia: You have a DrawingAPI and Shapes. When you want to draw a Shape with a specific DrawingAPI, you create a Shape instance and also give it it's DrawingAPI. Isn't this example AWFUL? I mean, why does the shape need to know what drawing API is drawing it?
A better example is the one provided in (2), where two different domains are mixed using a bridge that connects them. This is a much better example, but I would describe it as "mix two (or more) class hierarchies that interact together to perform something". Is this the real meaning of the Bridge DP?
