This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The purpose of the Bridge pattern is to decouple an abstraction from its implementation so that the two can vary independently. The participants of the pattern are: - Abstraction - RefinedAbstraction - Implementor - ConcreteImplementor
I understand perfectly that we can "design" both abstraction and implementation independently, because with the pattern they are not tightly coupled anymore. But I have difficulties in understanding how the abstraction can vary. Considering that the RefinedAbstractions are extensions of the Abstraction (i.e. they have more methods than their superclass), in which sense can they vary???
For example, consider the client code bellow:
But if I work directly with the concrete type, how can I switch from an abstraction to another, or this is not the "level" of variation that the pattern bridge proposes?
Originally posted by Alexandre Gazola: But if I work directly with the concrete type, how can I switch from an abstraction to another, or this is not the "level" of variation that the pattern bridge proposes?
You are correct, polymorphic usage of the "Concrete Abstractions" is not a goal of the bridge pattern.
The point is that you stabilize the relationship between the "Abstraction Abstract Class" (Window) and the "Implementation Abstract Class" (WindowImp). Note that "Window" has-a "Window Imp". So the "Abstraction" (Window) defines all of its methods in terms of the interface exposed by the "Implementation" (WindowImp). Now all the "Concrete Implementations" (XWindowImp,PMWindowImp) simply implement the interface of the "Implementation" Interface (WindowImp) without any regard for the "Concrete Abstraction" (IconWindow, TransientWindow) they serve. Similarly the "Concrete Abstractions" (IconWindow, TransientWindow), implement themselves in terms of the "Abstract Abstraction" (Window) without regard of the actual "Concrete Implementation" (XWindowImp,PMWindowImp) that is in place and in doing so the "Concrete Abstractions" (IconWindow, TransientWindow) may expose an entirely new interface.
However nothing is stopping you from defining your own interface for a number of "Concrete Abstractions" if you need them to be exchangeable.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Aug 30, 2006
Thank you guys. I think, as Peer said, that the general form of the Bridge pattern is to decouple abstractions from implementations. But nothing stops me from defining a common interface for my "concrete abstractions" and make them interchangeable. It true, the strategy is applied to the implementation hierarchy. The application of the Template Method to the abstraction hierarchy is possible, although I think it can be less common.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com