0

bridge .v. abstract factory

HEC 12 місяців тому оновлено Yurii B 10 місяців тому 1
For a given domain problem, say making shapes using different implementation (say to be drawn on a screen or displayed on a projector) it may be clear to use Bridge (abstraction variation de-coupled from implementation variation). However if the domain is perhaps making different types of houses using different materials (e.g. building from bricks or from straw) then would we consider AbstractFactory as an option (as well as Bridge)? If we then shift the domain problem a little further to say a Bakery that produces pie & pastry products with apple or banana fillings (so a family of fruit fillings across each product), we perhaps go for AbstractFactory in preference to Bridge. 

So it seems, there's a spectrum where Bridge may be best and where AbstractFactory may be best, for very similar domain problems.

My question is how to differentiate when to use Bridge and when to use AbstractFactory?

Well, they are different patterns: one for structuring stuff, other for creating stuff. So in case of abstract factory you want to create a family of product. Bridge in other hand is for separating two hierarchies or product families that can evolve independently (nothing creating here, just structuring stuff). You can think of an abstract factory that produces two hierarchies that later can be combined by bridge or something like that (doesn't feel right but still possible :) )