Abstract Factory Class Design Pattern | C# 

Sure.

Having an interface allows us to inject different implementations.

Hey, thanks for taking your time to comment. I don't claim to be an expert but here is what I think: 1) The idea is to disconnect client from the concrete factory implementation. At some point the abstract factory will have to give enough information about which concrete implementation to use; or better just return the implementation. 2) Code will have to figure out which concrete factory to use. Abstract factory or its childrens can encapsulate that code thus organizing everything nicely. sure you can use an interface thats your choice. I would suggest to understand the need of a design pattern and the problem itself rather than focusing too much on any specific type of pattern code implementation. The implementation can vary from project to project; it is the academics that make the mistake of believing a solution is final. Professionals know that only that solution is final which works and satisfies the project and client needs.

​@@CodeRadiance I agree with Ab Sh. Your abstract factory should be designed to create families of objects that go together, not to create one object of varying types. The reason for doing this would be the cases where certain derivations need to compose specific objects, but how these derivations behave depends on some larger overarching setting that it sits within. In other words, Abstract Factory can be described (in most cases) as a Factory that is composed of one or more factory methods, each of which return an abstract object. So a PersonFactory would have CreateArm(), CreateLeg(), etc. The type of person would specify the type arm/leg, etc. So you could have AthleticMan, AthleticWoman, SedentaryMan, SedentaryWoman. Both men would share similarities (example CreateBeard() ) which neither woman would implement. However, both Athletic instances would share stuff that the Sedentary subtypes wouldn't as well.

@@moe45673 Hey thanks for your response. So I get what you are saying. But at the same time a factory can have many different kinds of implementations as long as we are sticking to its core principles. Who is to say that I cannot have an abstract factory which will will act as a base for any existing/newly created factory in the project? No one can claim to be an expert on this broad topic; I am certainly not. If you just want to have a factory contract then use an interface. If you want to have some additional behavior attached then create an abstract factory; its simple as that. You want to construct and return a family of objects from the factory? Sure if that suits your needs then do that. I think that the sole purpose of an abstract factory should be to act as an abstract layer for any factory class so that when devs will construct new factory classes they will do so by remaining within the project framework's boundaries. This in turn makes sure that the system will not require much testing for these changes.