Introduction

Design patterns are reusable and documented solutions for commonly occurring problems in software programming or development.

In one of my previous article about Factory Pattern I spoke about what are different flavors of Factory pattern and how to choose between them. But I think there are some confusion with regards to Factory Method Pattern and Abstract Factory. So we will work on it.

Who should read this article?

If you have confusion understanding the difference between Factory Method Pattern and Abstract Factory Pattern you are at right place.

What these two are?

First of all both of them falls under Creational category and it means it will solves the problem pertaining to object creation.

Factory Method and abstract factory pattern all are about creating objects.

In this article I would like to emphasize on one more terminology that is Simple Factory.

Factory Method Pattern

In this pattern we define an interface which will expose a method which will create objects for us. Return type of that method is never be a concrete type rather it will be some interface (or may be an abstract class)

Note:- To understand when to use Simple Factory and when to use Factory Method Pattern click here.

2. Abstract Factory Pattern

In Abstract Factory we define an interface which will create families of related or dependent objects. In simple words, interface will expose multiple methods each of which will create some object. Again, here method return types will be generic interfaces. All this objects will together become the part of some important functionality.

Question – If every factory is going to create multiple objects and all those objects will be related to each other (means they will use each other) how this relating happens and who does that?

Answer –

There will be an intermediary class which will have composition relationship with our interface.

This class will do all the work, using all the objects got from interface methods.

This will be the class with which client will interact.

Let’s talk about a scenario.
We want to build desktop machine. Let see what will be the best design for that,

About the Author

By profession I am a Corporate Trainer. I do trainings on WCF, MVC, Business Intelligence, Design Patterns, HTML 5, jQuery, JSON and many more Microsoft and non-Micrsoft technologiees.Find my profile here

I'm working on a new kind of dependency injection framework. As soon as it is ready, I'm going to write an article .Auto-generation of factories and configurable factories, which I miss in this article, will be one of the central concepts.

Buddy, You must have added code snippets to make your article more clear, but this kind of mistakes leads to confusion, so better you support your article with graphs and visual presentations rather than code snippets if you want people to learn concepts.

It was just a comparison article and for complete source code demonstration i have provided a link.Hope it helped...And thanks a lot for your inputs...What i will do is, Soon i will add source code of complete project even here.

For any technical training related to .net ,OOPS and design patterns contact me on 9870148461 or at sukeshmarla@gmail.com

You did a great work explaining the Factory Method pattern and even explaining the wrong use of it, when there's nothing virtual, only a separate method to work as the factory.

Yet on the real cases I see some problems: In the Factory Method Pattern your factory exposes both GetCustomer and CreateCustomer as public. Honestly, I think that users will more naturally call the CreateCustomer method, as this is the one that seems to indicate creation. Such method should be hidden or, even better, only one public abstract method should exist. Why is the GetCustomer() doing those two doSomethingX() calls?

And on the Abstract Factory Pattern, you start by "For above problem statement we cannot use Abstract Factory Pattern as solution." To which problem we can't use it?

And your example is a problematic one. You apparently love to use real world examples that don't fit. The GetRam, GetHardDisk and GetMonitor aren't methods that need to exist as a family. They are simply 3 different factories put inside one multi-reponsibility factory. The big example is that your 2 implementations return a new LgMonitor();

The abstract factory pattern is useful when the family members have a notion of family. For example, we can have a factory of UI controls. The light theme may create all kinds of control, as long as they fit the light theme. The dark theme, well, it is the same, as long as they are dark. We don't expect to mix controls from a light theme and dark theme together.

I can't say the same about HardDisks and RAM and Monitors. As long as it is possible to connect them (and in this case we should see the computer's connections), I can use harddisks from any company with ram from any company and monitors from any company. This is the kind of situation that should avoid inheritance or a class for each combination. Each construction should be isolated.

So, using a more real example, the IDbConnection, IDbCommand etc already work as factories, yet we have the DbFactory type, which is capable of creating the connections, commands, parameters etc. It will not try to create SqlConnections and OracleCommands. It is either an entire Oracle family or an entire Sql Server family. And this is the purpose of the abstract factory pattern.