bridge pattern

[Vishakha Ahuja]

Hi,
Can anyone explain what this Bridge pattern does? I tried reading different books but don't understand the meaning of "decouple an abstraction from its implementation so the 2 can vary independently" Any examples ???

[Mark Herschberg]

Yeah, this is a complex pattern. I'll see if I can explain it properly.
Grand writes "The Birdge pattern is useful when there is a hierarchy of abstractions and a corresponding hierarchy of implementations." (I'm not convienced hierarchy is necessary, just that there be many implementations.)
Basically, you create a nice, simple implementation agnostic class to represent something. Then you have a series of concrete, kind of vendor specific, classes. You can't always stick the latter into the former easily, especially since he implementation classes may feel slightly different, so you need to bridge them.
Hmm, that's not very clear.
OK think of Java's AWT. You have a whole bunch of GUI classes, button, checkbox, etc. These are very nice, platform independent classes. They need to be implemented in a platform specific way (Windwos, Mac OS, X,Truffle, etc). So there's a set of implementation classes, like WindowButton and WindowCheckbox,and also MacButton and MacCheckbox (you'll find these in java.awt.peer, although my actual names are problably wrong). The JVM then uses the appropriate GUI component implementation on a aprticular OS when a new GUI object is created. To make it easier for the peer class to fit into the abstract GUI class (here abstract means high level concept, as opposed to can't instantiate), i.e. Button, there's a nice interface to let the two work together. This intrface defines the relationship between Button and <OS>Button. This interface is the bridge. This means the <OS><Widget> implementor simply needs to implement to the interface and then can trust that <Widget> can use it.
I think of it kind of like an adaptor for a set of implementation classes.
Does that help?
--Mark
[email protected]

[Desai Sandeep]

Mark,
I think I have got something out of your explanation.Please do let me know if I am correct.
I had read long time back that Sun had developed AWT model in scant 21 days.They were able to do so using the peer concept.This means if they had to define Window Frame, they did not start from scratch, by just made an interface which was able to call the platform specific Window Frame.This allowed them to develop their applications quickly.But perhaps, the disadvantage was the GUI used to take the look and feel of the underlying operating system.A Windows Button would look just like any other Windows button, same would be the case with other operating systems GUI.But, they soon realized that using the peer concept actually worked to their disadvantage.The peer was using the system process which is a heavy weight process as compared to Java's philoshopy of light-weight Threads.Hence we could see Sun working on a newer set of GUI - Java Swing, which has less number of heavy weight components as compared to AWT.However, there has to be some heavy-weight component in any GUI system , which has to interact with the OS - It can not be eliminated but can only be minimized.
I believe the interface (contract) between the System and the GUI developement (Swing, AWT), i.e. the peer could be thought of being developed on lines of Bridge Pattern.
Would like to hear your views on this.
Thanks in advance,
Sandeep
[This message has been edited by Desai Sandeep (edited May 24, 2001).]

[Mark Herschberg]

Well, it's hard for me to say why Sun developed it so quickly, although using well defined interfaces certainly would help terms work efficently in parallel.
I don't know much about the light-weight vs. heavy-weight threads used in GUIs. I do know the AWT used heavyweight objects, meaning peer objects rendered by the local OS. Swing uses lightweight obejcts, most of which can be handled by the JVM (or rather, most of their needs). I think, I'm definately pushing my limits. Now if this somehow correlates to the actual threads used by the OS and JVM, I don't know.

You are right that the peer classes were developed using the bridge pattern. An interface (the bridge) was defined so the peer class would know what the AWT class would expect from it. I'm not sure if Swing uses a similar model.
Generally, I suspect you would expect to see bridge classes where "the rubber meets the road" and the implementation of a particular family of functions would differ greatly, such as on different hardware or OS.

--Mark
[email protected]

[Desai Sandeep]

Originally posted by Mark Herschberg:
Generally, I suspect you would expect to see bridge classes where "the rubber meets the road" and the implementation of a particular family of functions would differ greatly, such as on different hardware or OS.

Just confirming if I got it right .
Can we say all the interfaces that Sun developed are based on bridge pattern.For instance, Sun provides a ODBC-JDBC driver for connecting any ODBC driver with its JDBC driver.There is JNDI SPI, which interacts with different directory servers like LDAP, Netscape Directory Services.Is the implementation of JNDI SPI a bridge between the actually directory server and the JNDI API?
Thanks in advance,
Sandeep

[Ramesh Donnipadu]

Sandeep,
I thought JDBC-ODBC bridge is an example of facade pattern. The reason being,
1. It hides a lot of complex code which the client does not need to know.
2. It is a just a collection of methods. Not object oriented by nature.
Could you justify why do you think it is a bridge pattern?
Thanks,
Ramesh

[Desai Sandeep]

Ramesh,
I am not sure if JDBC-ODBC bridge is based on Facade Pattern.AS the name itself reveals, it is bridge.
I understand Bridge Patterns, as those which connect two different technologies together.As Mark said - where "the rubber meets the road".I presume, this is what is happening in case of ODBC and JDBC case.If there is no JDBC driver on the client machine for a particular DBMS system, you would need to configure the ODBC driver to provide JDBC access to the databases through these drivers.This actually means you have written an interface, which actually is able to talk (bridge) to the ODBC existing on your machine.
Hope this helps,
Sandeep
BTW, I have expressed my views on Facade Patterns here
-- Sandeep
[This message has been edited by Desai Sandeep (edited May 25, 2001).]