Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Doubt about the Bridge Design Pattern

 
Alexandre Gazola
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Alexandre Gazola
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic