Click here to Skip to main content
13,901,142 members
Click here to Skip to main content
Add your own
alternative version

Stats

23.3K views
302 downloads
38 bookmarked
Posted 9 Oct 2016
Licenced CPOL

Factory Patterns - Abstract Factory Pattern

, 10 Oct 2016
Rate this:
Please Sign up or sign in to vote.
In this article we will understand Abstract Factory Pattern. This article is third part of Factory Patterns article series and continuation of Part 1 (Simple Factory Pattern) and Part 2 (Factory Method Pattern).

Introduction

In this article we will understand Abstract Factory Pattern. This article is third part of Factory Patterns article series and is the continuation of Part 1 (Simple Factory Pattern) and Part 2 (Factory Method Pattern). In first part we have learned Simple Factory Pattern and in second part we have learned Factory method Pattern, now its turn for Abstract Factory Pattern. If you haven’t gone through the first and second part, I will suggest you to do so then continue with this article.

Outlines

Part 1 - Simple Factory Pattern

Part 2 - Factory Method Pattern

Part 3 - Abstract Factory Pattern

  • What is Abstract Factory Pattern
  • When to use Abstract Factory Pattern
  • Understand Definition with Example
  • Problem with Abstract Factory Pattern

What is Abstract Factory Pattern

Abstract Factory Pattern is a part of Gang of Four (GoF) book and comes in the category of Creational Pattern. Following is the definition of Abstract Factory Pattern taken from Gang of Four (GoF) book

“Provide an interface for creating families of related or dependent objects without specifying their concrete classes.”

We will understand this definition in detail under "Understand Definition with Example" section of this article.

When to use Abstract Factory Pattern

Whenever we need to create different kind of related objects (of a group/set) then Abstract Factory Pattern is a choice. It provides different kind of Factories. Each factory will create a particular kind of related objects. That's why sometime we call Abstract Factory Pattern as Factory of Factories. Simple Factory Pattern and Factory Method Pattern provide one kind on objects only (in our examples all those objects were of type IFan).

Note: Abstract Factory Pattern can be use along with Factory Method Pattern if needed.

Now, other than Fan, if we need to create more electrical equipments like Tubelights or Switches we will go for Abstract Factory. To make it more clear, let's extend the scenario where we will need to create different kind of related objects of a group (objects under group of Electrical Equipments). We will continue with the similar example which we took in part 2 of this article series.

Now let’s understand extended scenario: There is a electrical company which makes various kind of electrical equipments namely Fan and Tubelight. Currently company is in India only and called as Indian Electrical company. Now same company wants to setup new branch in US namely US Electrical company which would be manufacturing electrical equipment called Fan and Tubelight as per US standards. So here we have two kind of group of Electrical Equipments - called as Indian Electrical Equipments and US Electrical Equipments. And related objects in these groups are Fan and Tubelight (There may be more such electrical equipments).

Understand Definition with Example

Let’s understand the definition of Abstract Factory Pattern with the help of above mentioned scenario. First create design diagram of above mentioned scenario and try to correlate the definition with this scenario. Following is the design diagram shows the required entities to implements above mentioned scenario.

Abstract Factory Classes

In above diagram IElectricalFactory provides an interface to the client for creating families of related or dependent objects. Here we have two concrete implementation of that interface - IndianElectricalFactory and USElectricalFactory classes. These two classes are manufacturing two different type of families of related objects - Fan and TubeLight. IndianFan and IndianTubelight belong to IndianElectricalFactory family. USTubelight and USFan classes which belong to a USElectricalFactory family.

Main Component/Participants of Abstract Factory Pattern

  • AbstractFactory (IElectricalFactory)
  • ConcreteFactory (IndianElectricalFactory, USElectricalFactory)
  • AbstractProduct (IFan, ITubeLight)
  • ConcreteProduct (IndianFan, IndianTubelight, USFan, USTubelight)

Following is step by step implementation of above mentioned scenario:

Create two interface called IFan and ITubelight.

interface IFan
{
    void SwithOn();
}

interface ITubelight { }

Create Two concreate classes as given below by implementing IFan and ITubelight. Implementation of interfaces will be according to Indian electrical equipment standard.

class IndianFan : IFan { }

class IndianTubelight : ITubelight { }

Create an IElectricalFactory interface, this interface is actual Abstract Factory which will create families of related objects.

interface IElectricalFactory
{
    IFan GetFan();
    ITubelight GetTubeLight();
}

Create an IndianElecticalFactory class and inherit it from IElectricalFactory interface. It will implementation of two methods called GetFan and will GetTubeLight. GetFan returns object of IndianFan class as IFan interface is implemented by IndianFan class. Similarly GetTubeLight will return the object of IndianTubelight class.

class IndianElectricalFactory : IElectricalFactory
{
    public IFan GetFan()
    {
        return new IndianFan();
    }

    public ITubelight GetTubeLight()
    {
        return new IndianTubelight();
    }
}

So far IndianElecticalFactory class is ready to create IndianFan and IndianTubelight. Now let’s see how client can create them.

static void Main(string[] args)
{
    IElectricalFactory electricalFactory = new IndianElectricalFactory();
    IFan fan = electricalFactory.GetFan();
    fan.SwithOn();
    Console.ReadKey();
}

As we discussed above section, company wants to setup new electrical company in US and company name will be USElectricalFactory. In the same application we will add two new classes called USFan and USTubelight by implementing required interfaces. Here implementation of IFan and ITubeLight interfaces will be according to US electrical equipment standard.

class USFan : IFan { }

class USTubelight : ITubelight { }

Finally create USElectricalFactory class which is also inherited from IElectricalFactory.

class USElectricalFactory : IElectricalFactory
{
    public IFan GetFan()
    {
        return new USFan();
    }
    
    public ITubelight GetTubeLight()
    {
        return new USTubelight();
    }
}

Now if client wants to get USElectrical equipment then this can be done just by doing one change in client code, as shown below:

//IElectricalFactory electricalFactory = new IndianElectricalFactory();
IElectricalFactory electricalFactory = new USElectricalFactory();

Problem with Abstract Factory Pattern

Only problem may come if we change the interface provided by Abstract Factory itself. Thats rare and every programs which follows the design philosophy of "Program to an interface, not an implementation" suffers with this problem. Same problem is discussed at this stackoverflow page. In our case, if any change occurs in IElectricalFactory interface all factories need to change.

Conclusion

In this article, we had a walkthrough to learn Abstract Factory Pattern and its use. We understood the context of Abstract Factory Pattern and how to use it to enhance maintainability of application. Thanks for reading. Your comments and suggestions for improvement are most welcome.

References

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Snesh Prajapati
Software Developer
India India
I am a Software Developer working on Microsoft technologies. My interest is exploring and sharing the awesomeness of emerging technologies.

You may also be interested in...

Comments and Discussions

 
QuestionAbstract Factory Pattern and Factory Pattern seems same as according to your code Pin
vishnu_cs4717-Feb-19 23:58
membervishnu_cs4717-Feb-19 23:58 
QuestionCorrection Pin
Shiv Ratan25-Feb-18 4:31
memberShiv Ratan25-Feb-18 4:31 
QuestionNice One Pin
Prdissa23-Jan-17 18:17
memberPrdissa23-Jan-17 18:17 
PraiseExcellent! Pin
stanino7-Nov-16 9:41
memberstanino7-Nov-16 9:41 
AnswerRe: Excellent! Pin
Snesh Prajapati7-Nov-16 15:05
professionalSnesh Prajapati7-Nov-16 15:05 
QuestionFactory Design Patern Pin
DeyChandan12-Oct-16 6:06
memberDeyChandan12-Oct-16 6:06 
AnswerRe: Factory Design Patern Pin
Snesh Prajapati12-Oct-16 16:37
professionalSnesh Prajapati12-Oct-16 16:37 
QuestionFactory Design Patern Pin
DeyChandan12-Oct-16 6:06
memberDeyChandan12-Oct-16 6:06 
AnswerRe: Factory Design Patern Pin
Snesh Prajapati12-Oct-16 16:37
professionalSnesh Prajapati12-Oct-16 16:37 
PraiseThe Best Article I Have Ever Read on Factory Patterns Pin
Patrick Skelton10-Oct-16 2:12
memberPatrick Skelton10-Oct-16 2:12 
AnswerRe: The Best Article I Have Ever Read on Factory Patterns Pin
Snesh Prajapati10-Oct-16 2:27
professionalSnesh Prajapati10-Oct-16 2:27 
PraiseGood explanation Pin
vbalajich10-Oct-16 0:46
membervbalajich10-Oct-16 0:46 
AnswerRe: Good explanation Pin
Snesh Prajapati10-Oct-16 1:14
professionalSnesh Prajapati10-Oct-16 1:14 
GeneralMy vote for 5 Pin
Shambhoo kumar9-Oct-16 20:26
professionalShambhoo kumar9-Oct-16 20:26 
AnswerRe: My vote for 5 Pin
Snesh Prajapati9-Oct-16 21:33
professionalSnesh Prajapati9-Oct-16 21:33 
GeneralRe: My vote for 5 Pin
Shambhoo kumar10-Oct-16 19:35
professionalShambhoo kumar10-Oct-16 19:35 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web05 | 2.8.190306.1 | Last Updated 10 Oct 2016
Article Copyright 2016 by Snesh Prajapati
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid