Possible Duplicate:
Understanding the bridge design pattern

I have read lots of material about the bridge design pattern:

  1. http://www.codeproject.com/Articles/3151/Illustrated-GOF-Design-Patterns-in-C-Part-II-Struc
  2. http://sourcemaking.com/design_patterns/bridge
  3. http://en.wikipedia.org/wiki/Bridge_pattern
  4. Understanding the bridge design pattern
  5. 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?

marked as duplicate by user4051, Walter, user7007, Blrfl, Martijn Pieters Feb 3 '13 at 13:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    I'm sorry, but why was this question closed? At least a comment for good manners. I did my HW :-( – vainolo Feb 3 '13 at 22:01