Bridge Design Pattern...

[James Turner]

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.

Regards,

James.

[T Ram]

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]

Is that not the same of coding to interfaces?

James.

[Rahul Thakur]

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.

HTH.

Cheers