When I want to learn something new, I ask myself, what I lost when I don't learn that thing. I am going to learn some design patterns and everything is good. But when I arrived to Bridge Design Pattern I fell in problem. Really I can not imagine when to use this design pattern. And I know there is another links in google and stackoverflow like this.
But can anyone say that, what we lost if we forget Bridge Design Pattern and skip try this pattern?
The Bridge pattern is simply noticing a couple of converging responsibilities and separating them. I'll use The Gang of Four (TGF)'s example because I think its a really good one:
You have a Window interface, with two subclasses: XWindow (based on the X Window Manager) and PMWindow (based on IBM's Presentation Manager (PM) Window Manager... which I've never heard of).
ie:
interface Window {}
class XWindow : Window {}
class PMWindow : Window {}
The problem with continuing in our traditional inheritance approach is that if you specialize Window on an aspect other than its platform dependence (ie, you have some responsibility that is orthogonal to the one you created the inheritance tree to support), you need to use the bridge pattern, otherwise your class hierarchy will grow in depth geometrically. I think a good way to think of bridge as a combination of inheritance and composition.
That's pretty wordy. Going back to the TGF example: what if you want an IconWindow and a TransientWindow (something like a glass pane). The concept of "Icon vs Transient" and "PM vs X" are two orthogonal ideas, but they're both trying to get on the same inheritance tree. If don't use the bridge pattern, what you'll have to do is create two new interfaces inheriting from the first, and a slew of classes beneath them:
interface Window {}
class XWindow : Window {}
class PMWindow : Window {}
interface IconWindow : Window {}
class XIconWindow : XWindow, IconWindow {}
class PMIconWindow : PMWindow, IconWindow {}
interface TransientWindow : Window {}
class XTransientWIndow : XWindow, TransientWindow {}
class PMTransientWindow : PMWindow, TransientWindow {}
With the bridge pattern you would separate those two responsibilities onto two inheritance trees:
interface Window {}
class IconWindow : Window {} //this class...
class TransientWindow : Window {} //and this one will keep a private reference to aWindowImp
interface WindowImp: Window {}
class XWindowImp : WindowImp {}
class PMWindowImp : WindowImp {}
Much cleaner, much better responsibility segregation, and much easier to write and consume!
I believe that this design problem and the oddities of even the bridge object tree were actually some of the issues driving the design of Mix-ins in Scala. Using C++'s multiple inheritance, you'd statically couple any implementations to their windowing system. In other words, you'd have the same number of types as the non-bridge pattern but they'd probably be empty classes and you can of course refer to them by the abstraction, which makes it fairly easy to consume.
The advantages of a bridge are that abstraction and implementation be decoupled. The implementation is also changed dynamically at run time and the extensibility of abstraction and implementation is improved.
By specifying a parameter in the generation of an abstraction, the implementation can be chosen also for the implementation of the client is completely hidden. A strong increase in the number of classes can be avoided.
