Abstract factory design pattern.

Background -

Please read the factory concept or skip if you have a good understanding of it.

When you have a requirement to run your product on multiple operating systems (i.e., Windows, RedHat Linux, Mac, Solaris, HPUX, etc.), the only difference is how your object is getting created on different platforms. The business logic and look and feel of the product has to remain the same on all OS.

You are creating the same set of objects but for different–different OS families. Here you have to handle the creation part as per OS, yes we are talking about a class whose core behavior is to create objects.

Whenever you get such kind of situations where the same set of objects are getting created differently depending upon the family, they belong to. You shall start thinking about abstract factory design pattern.

Abstract factory design pattern –

It is A class-based design pattern (not object-based). Very important for any product where the designer is looking at portability as one of the crucial aspects. It also maintains consistency among different platform targeted projects.

UML diagram representation –

UML structure of abstract factory design pattern (Click on picture to see zoom view).

Example -

Example of abstract factory design pattern (Click on picture to see zoom view).

Different components - 

• Abstract factory - We declare pure virtual functions. Remember one thing, the same set of objects gets created for different families. So the interface which you expose to the outer world should be able to create a full collection of objects. For example, we have a requirement to create 3 objects {obj1, obj2, and onj3} for two independent platforms. Abstract factory should expose an interface to create all three object for all families.
• Concrete factory
• Abstract product
• Concrete product
• Client

C++ code -

 #include<iostream>
 using namespace std;

 class Car
 {
  public:
  virtual void build() = 0;
 };

 //*********************************************************************************
 class EcosportForIndia : public Car
 {
  void build()
  {
  cout<<"Bulding ecosport for India"<<endl;
  }
 }; 

 //*********************************************************************************
 class EcosportForUSA : public Car
 {
  void build()
  {
  cout<<"Bulding ecosport for USA"<<endl; 
  }
 };

//*********************************************************************************
class AccordForIndia : public Car
 {
  void build()
  {
   cout<<"Bulding accord for India"<<endl;
  }
 };

//*********************************************************************************
class AccordForUSA : public Car
 {
  void build()
  {
   cout<<"Bulding accord for USA"<<endl;
  }
 };

 //*********************************************************************************

 class AbstractFactory
 {
  public:
  virtual Car* BuildEcosport() = 0;
  virtual Car* BuildAccord() = 0;
 };

 //*********************************************************************************
 class IndianFactory : public AbstractFactory
 {
  public:
  
  Car* BuildEcosport()
  {
   return new EcosportForIndia;
  }
  Car* BuildAccord()
  {
   return new AccordForIndia;
  }
 };
  
 //*********************************************************************************
 class USAFactory : public AbstractFactory
 {
  public:
  
  Car* BuildEcosport()
  {
   return new EcosportForUSA;
  }
  Car* BuildAccord()
  {
   return new AccordForUSA;
  }
 };

  AbstractFactory *factory;
 //*********************************************************************************
 int main(int argc, char** argv)
 {
 //#define IND -- We can comment or uncommant this line of code according to our req.
 #ifdef IND
    factory = new IndianFactory;
 #else // WINDOWS
    factory = new USAFactory;
 #endif
 
 Car *newCar1 = factory->BuildEcosport();
 newCar1->build();

 Car *newCar2 = factory->BuildAccord();
 newCar2->build();
 }

 }

Thanks for reading it. To learn more about design patterns and basic design principles, please see my web page.