Enterprise Integration Zone is brought to you in partnership with:

Ayende Rahien is working for Hibernating Rhinos LTD, a Israeli based company producing developer productivity tools for OLTP applications such as NHibernate Profiler (nhprof.com), Linq to SQL Profiler(l2sprof.com), Entity Framework Profiler (efprof.com) and more. Ayende is a DZone MVB and is not an employee of DZone and has posted 485 posts at DZone. You can read more from them at their website. View Full User Profile

Design Patterns in the Test of Time: Bridge

11.20.2012
| 6871 views |
  • submit to reddit

 

The bridge pattern is a design pattern used in software engineering which is meant to "decouple an abstraction from its implementation so that the two can vary independently".The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

More about this pattern.

Bridge is quite complex, mostly because it is composed of Abstraction, Refined Abstraction, Implementor and Concrete Implementor. Here is a concrete example (pun intended):

  • Abstraction: CImage
  • Refined Abstraction: CBmpImage, CJpegImage
  • Implementor: CimageImp
  • Concrete Implementor: CWinImp, COS2Imp

In general, I don’t like complex things, and of the top of my head, I can’t think of a time when I used this approach. Until such time when I can see a really good reason why I would want to do something like this, I see very little reason to bother.

Recommendation: Avoid, there are simpler options to solving those sort of problems.

Published at DZone with permission of Ayende Rahien, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lund Wolfe replied on Thu, 2012/11/22 - 5:59pm

I think we use this pattern a lot more than we realize, and we may never put the name Bridge in the name of a class.  We need a single class from the client perspective that acts as two classes and two hierarchies that can change and be further subclassed, so the main client class delegates to an aggregate class hierarchy.

I think I'll keep it, and the concept, in my bag of tricks.

Lloyd Shove replied on Sun, 2012/11/25 - 7:32pm


I like this series of design pattern article.... but...

"there are simpler options to solving those sort of problems."
I think the article and the comments would be much more interesting if you offered up a simpler solution for this and other examples.

Keep them coming.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.