Abstract Factory Pattern

Abstract Factory Pattern

Well you see when u read the name of these patterns you will get a small hint about it. Not just what they are but also how well you are going to understand it. To me this abstract factory pattern was too abstract after third reading too. But I was actually all set to under stand it so I decided to take experts help.

Well you might also be knowing some guys around you who knows everything, I mean everything. So I also happen to know such a person who is design and C/C++ guru. I took his help and believe me or not he made it crystal clear. In fact that was the reason I thought of this idea of starting a page that will explain all the patterns as if they are just piece of cake. I am trying to get the guru to start writing on this page but it seems he is too busy, but I will try to contribute a little on this page.

Ok lets not digress and talk about abstract factory. Well I feel that there are some gaps in my write up for factory. So lets just try to see factory pattern in a glance.



Factory Pattern: You know you have to create a product so first define an interface the product should implement. Then you also know that you need a factory so define an interface for that too. Lets sat IProduct and IFactory. Now you need a concrete factory to create concrete products, Product and Factory. Now what you need it to create a Product in a factory so use virtual construction mechanism for that and then create a factory in your application to get the actual product. I mean if you read at the post#3 I am hoping it would be clear.(at-least that’s what I think). Also, the explanation of virtual construction mechanism will not get clear just by reading passages. For that we just have to stare at the code and write a code like that our-self to understand it. Believe me even if reading the passage explained everything sit down and write the code.

Ok now talk about the abstract factory, the reason I wrote the above paragraph is that once we know Factory pattern you know this pattern. Ok so lets start with bookish definition:

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

Sound pretty abstract isn’t it. I’ve told you. Ok so lets just do a little post mortem here. This definition can be broken into two parts and together they explains factory pattern

1. Provide an interface for creating families of related or dependent objects
2. -without specifying their concrete classes.

Ok now lets look at the second part first, does it look familiar. Well to me it does. It is what we attain from virtual construction mechanism isn’t it. So one problem is solved that we now know that we can use interface in the factories to create the actual concrete products

And to explain the first part just looks at the good old picture



Here actually we want the factory to create a family of products, meaning A1 will be required when B1 is required, A2 is required when B2 is required. The combination of A1-B2 and B1-A2 will never be required. This means these products A1-B1 or A2-B2 are related or dependent.

Also of you look at the picture you will observe that it is actually a factory pattern with two concrete factories. Each of which is responsible to create a family of products. The only difference is that here the factories will actually be using the concrete class instead of the interface of products because the factories are supposed to create only a specific set of products and so it should not be using the product interface.

Ok now lets do the usual and try to visualize this problem in C++ world.

Lets say we have some plant running to supply show parts to some shoe companies. We are mainly dealing in formal shoes and sport shoes. And our specialties are shoe sole and shoe body.

Now our requirement is that
• When we need SportShoeSole, we need SportShoeBody.
• When we need FormalShoeSole, we need FormalShoeBody.
No other combination is possible .

So now we can safely say that problem requires abstract factory pattern.

Lets start with specifying our favorite, the interface for sole and body

//----------------------------------------IShoeSole interface----------------------------------
class IShoeSole
{
protected:
IShoeSole(void);
public:
~IShoeSole(void);

static IShoeSole* CreateSole();

};

//--------------------------------IShoeBody interface------------

class IShoeBody
{
protected:
IShoeBody(void);
public:
~IShoeBody(void);

static IShoeBody* CreateBody();
};

Well looks fairly simple and we also know the create function returning interfacevpointers are to facilitate the virtual construction.

//--------------------------------IShoefactory interface-------------

Now lets define the interface for the factory classes.

class IShoeFactory
{
protected:
IShoeFactory(void);
public:
~IShoeFactory(void);

static IShoeFactory* CreateShoeFactory();

//Factory method to create shoe
virtual IShoeSole* CreateSole() = 0;
virtual IShoeBody* CreateBody() = 0;
};

Ok so now we have all the interfaes in place lets start writing the concrete classes.

Lets write down the classes requred for our show soles ans bodies

//---------------------- SportShoeSole class------------------------
class SportShoeSole : IShoeSole
{
private:
SportShoeSole(void);
public:
~SportShoeSole(void);

static IShoeSole* CreateSole()
{
return new SportShoeSole();
}

};
//------------------ FormalShoeSole class-----------------------------
class FormalShoeSole : IShoeSole
{
private:
FormalShoeSole(void);
public:
~FormalShoeSole(void);

static IShoeSole* CreateSole()
{
return new FormalShoeSole();
}
};


//------------------- SportShoeBody class-----------------------------
class SportShoeBody: IShoeBody
{
private:
SportShoeBody(void);
public:
~SportShoeBody(void);

static IShoeBody* CreateBody()
{
return new SportShoeBody();
}
};


//------------------- FormalShoeBody class----------------------------
class FormalShoeBody : IShoeBody
{
private:
FormalShoeBody(void);
public:
~FormalShoeBody(void);

static IShoeBody* CreateBody()
{
return new FormalShoeBody();
}
};


Now it seems we have all the requried classes in place. Now what we need is actual factories that will be sreating the parts for sport shoes and formal shoes. So what are we waiting for we know virtual consstruction, we know singleton lets go and implement these factories.

//-------------------SportShoe factory--------------------------------
IShoeFactory* SportShoeFactory::instance = 0;

class SportShoeFactory:IShoeFactory
{
private:
SportShoeFactory(void);

static IShoeFactory* instance;

public:
~SportShoeFactory(void);

static IShoeFactory* CreateShoeFactory()
{
if(0 == instance)
{
instance = new SportShoeFactory();
}
return instance;
}

//Factory method to create shoe
IShoeSole* CreateSole()
{
return SportShoeSole::CreateSole();
}
IShoeBody* CreateBody()
{
return SportShoeBody::CreateBody();
}
};

//----------------------FormalShoe factory------------------------
IShoeFactory* FormalShoeFactory::instance = 0;

class FormalShoeFactory : IShoeFactory
{
private:
FormalShoeFactory(void);

static IShoeFactory* instance;

public:
~FormalShoeFactory(void);

static IShoeFactory* CreateShoeFactory()
{
if(0 == instance)
{
instance = new FormalShoeFactory();
}
return instance;
}

//Factory method to create shoe
IShoeSole* CreateSole()
{
return FormalShoeSole::CreateSole();
}
IShoeBody* CreateBody()
{
return FormalShoeBody::CreateBody();
}
};

Ok now whatever we havve discussed in article #1 and #3 have been fully utilized in writting these factories. Now since we have all the product classes and factories lets look at the client code.

Any client that want to create the sport shoe products will just have to do

IShoeFactory *fac;

//Now if we need sport shoe
fac = SportShoeFactory::CreateShoeFactory();

fac->CreateBody();
fac->CreateSole();


and if he wants to get all the formal shoe products then

IShoeFactory *fac;

fac = FormalShoeFactory::CreateShoeFactory();

fac->CreateBody();
fac->CreateSole();

see, the cliennt code so simple and we can create any type of product without really knowing the concrete product.

So lets just try to look the code that we wrote and compare ot with the class diagram.

AbstractFactory = IShoeFactory
AbstractProductA =
AbstractProductB =

ConcreteFactory1 = FormalShoeFactory
ConcreteFactory2 = SportShoeFactory

ProductA1 = FormalShoeSole
ProductA2 = SportShoeSole

ProductB1 = FormalShoeBody
ProductB2 = SportShoeBody

So now we can visualize our implementation in terms of class diagram specified above.

Now to end lets just look at when should we use abstract factory pattern (taken as is from GOF)

• The system shall be "platform-independent"
• The system shall be independent of how its constituent pieces are created, composed, and represented.
• The system shall be configured with one of multiple families of products.
• A family of products designed to be used together shall have their relationship constraints enforced.
• "case" statements are a maintenance nightmare - they shall be avoided.

That’s it we have the Abstract factory implemented here. Well I have received a comment that I should also explain the usage and other variations in the patterns too in when I explaining a pattern, well I just want to say that I am not skipping those things, its just that I am not putting everything in one post. Lets understand the basic implementations first and then we can see the variations and common usage of the patterns, once we have grip and understanding on the patterns.