Bridge Design Pattern
zi...@mailinator.com
I'm puzzled by this Bridge Design Pattern as described in the GoF book.
Firstly, is this simply a glorified name for the PIMPL idiom? If so
(if they are
basicly the same), why is PIMPL considered an idiom, and not a Design
Pattern?
Secondly, in the GoF book, they claim that by decoupling interface and
implementation (by means of providing an association with an
implementor
object), we can now vary them independently.
What can that possibly mean? If I add something new in the interface,
I
will need to add the implementation for that new feature.
I think I miss the whole point of this Design Pattern.
Thank you for any help you may offer.
Regards,
-Zico
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Daniel T.
> I'm puzzled by this Bridge Design Pattern as described in the GoF
> book.
>
> Firstly, is this simply a glorified name for the PIMPL idiom? If so
> (if they are basicly the same), why is PIMPL considered an idiom,
> and not a Design Pattern?
The pimpl idiom is a degenerate form of the bridge pattern. I think it
is called an idiom because it is C++ centric. It isn't a full bridge
because there is only one Implementor, rather than a family of them.
> Secondly, in the GoF book, they claim that by decoupling interface
> and implementation (by means of providing an association with an
> implementor object), we can now vary them independently.
>
> What can that possibly mean? If I add something new in the
> interface, I will need to add the implementation for that new
> feature.
>
> I think I miss the whole point of this Design Pattern.
Anytime you implement the functions of a class exclusively using the
interface of some other class, you are creating a bridge pattern. The
client of the Abstraction class you are implementing could conceivably
get an object of the Implementor type that your class uses and call its
functions directly, but he doesn't because your Abstraction class
provides convenience.
Hope this helps. For more information, I suggest you try
comp.software.patterns or comp.object.
t.le...@rtsgroup.net
> I
> will need to add the implementation for that new feature.
>
Of course, if you change the interface (bridge frontend) all depending
sources have to be re-compiled, but in a good design you shouldn't be
forced to change the interface constantly!
Changes to the implementation (bridge backend) - in contrast - are done
frequently; this changes shouldn't have affects to sources <<using>>
the bridge frontend and that's the meaning of decoupling by the bridge
pattern.
Another example of decoupling is the "forward declaration"! In your
class you need members of other classes BUT you don't want others to
include additional headers by using your header! Same principle ->
decoupling!
Another decoupling is using creator factories - often in combination
with bridges!
Hint: If you're not very well with some design patterns make a simple
test programm (int main....) to see how it's working.... (play with it
and you see...)