• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Doubt about the Bridge Design Pattern

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
I am mighty! And this is a mighty small ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic