File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Doubt about the Bridge Design Pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Doubt about the Bridge Design Pattern" Watch "Doubt about the Bridge Design Pattern" New topic
Author

Doubt about the Bridge Design Pattern

Alexandre Gazola
Greenhorn

Joined: Aug 30, 2006
Posts: 4
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?

Hope somebody can help me
thanks a lot
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
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.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Alexandre Gazola:

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)


It doesn't have to have more methods than their superclass - it simply can implement them differently.

Bridge basically is a combination of Template Method with Strategy. See http://today.java.net/pub/a/today/2004/10/29/patterns.html for a good example.


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
Alexandre Gazola
Greenhorn

Joined: Aug 30, 2006
Posts: 4
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.
 
GeeCON Prague 2014
 
subject: Doubt about the Bridge Design Pattern