Search code examples
design-patternsabstract-factorybridge

Desing Pattern for DB Enacapsulation - Brigde Vs Abstract Factory


Few days back, our team was having discussion on design patterns for flexible DB implementation - Oracle, MYSql etc.

We discussed Bridge pattern and Abstract Factory pattern.

I was in favor of Abstract Factory as its flexible, easy to implement and Client doesn't know whats the underlying DB implementation. But my other team mates preferred Bridge over Abstract Factory. They mention that is even more flexible and easy to maintain when class hierarchy grows n all..

I am still not satisfied why we can't use Abstract Factory and I am looking for your suggestions and good references where I cam compare both of there pattern w.r.t different DB Implementations.


Solution

  • As has been said, AbstractFactory is about creating things. In fact, an abstract factory can create a Bridge patern object. So the two are not mutually exclusive.

    Personally, I find Bridge to be over-complicated for a lot of scenarios, and prefer to just abstract things away behind a simple façade pattern, such as when using the Repository pattern.

    But, Bridge may be more useful if you intend to define a standard operations around multiple implementation types. It's over-engineering, in my opinion, if you just want to create an abstraction that allows you to swap to a different backend sometime in the future. If you're going to use different back-ends at runtime then it may be appropriate.