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.
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.
Sometimes you feel like a nut. Sometimes you feel like a tiny ad.
a bit of art, as a gift, the permaculture playing cards