File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Bridge Design Pattern... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Bridge Design Pattern..." Watch "Bridge Design Pattern..." New topic

Bridge Design Pattern...

James Turner
Ranch Hand

Joined: May 10, 2004
Posts: 194
Hi Guys,

I have a question about the Bridge design pattern. Maybe I don't understand it well enough, but it seems to me that the bridge pattern is useless in Java.

The Bridge pattern is great when using C++ for example because it does not have interfaces therefore to spearate the interface from the implementation meant to use an abstract class.

With Java interfaces, dosn't this negate the usage of the pattern completely within Java and even C#?

I'd like to get some opinions on this as I can't seem to come up with scenarios where the Bridge pattern would be needed due to simply being able to code to interfaces in our modern languages.



James<br />SCJP 1.4 - 92%<br />SCJD - 93%<br />SCWCD 1.4 - 95%<br />SCBCD 1.3 - 100%<br />SCEA - 92%
T Ram

Joined: Sep 27, 2005
Posts: 27
In the Bridge pattern, We can easily plug a new functionalities in this scenario and modifying the existing implementations without impacts on the client side.
For example, if any application logic changes frequently, we can use this in that application scenario.
James Turner
Ranch Hand

Joined: May 10, 2004
Posts: 194
Is that not the same of coding to interfaces?

Rahul Thakur

Joined: Nov 21, 2005
Posts: 3
Hi James,

Bridge basically separates 'abstraction' from 'implementation' and allows to interchange implementations (pls refer GOF).

I will try to explain with a real life example. Not the best ones but I hope you will get the picture.

We had a case where we were using 2 different RDBMSs (one for dev and one for uat/prod). So, we had
- 2 different Data Access Object implementations ('implementation' participant in Bridge),
- and a Service abstraction ('abstraction' participant in Bridge).
- The Service abstraction was further refined/extended as a) JDBC Service and b) Indexed Service (for lucene based indexing).

Now comes the interesting part...
If you observed we could now change/switch the different abstractions and DAO implementations with a configuration change and use the differnt Services (JDBC or Indexing service) in different scenarios.


I agree. Here's the link:
subject: Bridge Design Pattern...
It's not a secret anymore!