Desing Pattern for DB Enacapsulation - Brigde Vs Abstract Factory [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

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.

Answer 1

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.

Answer 2

I don't see these two as being mutually exclusive. Abstract Factory is about how things get created. Bridge doesn't kick in until after things have been created.

I see Abstract Factory as something like calling Amazon up and ordering something. Amazon knows how to get or make that thing, and it doesn't concern me how that happens.

Bridge is more like "what is the nature of the box and packaging materials" that the item will be placed in. The base objects need to be made and fitted together, and Abstract Factory is a good way to make that happen.

If I had to take sides, I'd be more inclined to lean to your side, since the fact that they care so much about making the concrete implementation(s) variable and the path to it so circuitous suggests to me that probably they want too many things to know about the database object once it's finally created. I wouldn't be surprised if someone wants it to be globally accessible or they want the Implementors to reach out and grab an Implementation from a global object.

If you keep access to the service layer closely regulated (for instance, only allowing Views to make requests of some third party, such as a Controller layer), it matters a lot less how the service layer is created and what it actually is--only one thing actually knows about it anyway.

Answer 3

As has been mentioned the Abstract Factory pattern is a pattern to create objects and the Bridge is a structural pattern, therefore their usage is not mutually exclusive.

Whether to use a Bridge or a simple Strategy pattern using a generalization comes down to the following questions:

Do you need to switch the strategy during runtime? Would be forced to create more than one implementation class for each strategy?

If either of those two questions yield a yes answer it is likely that the Bridge pattern will benefit you.

If the following question is true then you may need an Abstract Factory.

Do you need to create instances without knowing the concrete type?