C++ Programming/Code/Design Patterns/Creational Patterns

From Wikibooks, open books for an open world
Jump to: navigation, search

Creational Patterns[edit]

In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.

In this section of the book we assume that the reader has enough familiarity with functions, global variables, stack vs. heap, classes, pointers, and static member functions as introduced before.

As we will see there are several creational design patterns, and all will deal with a specific implementation task, that will create a higher level of abstraction to the code base, we will now cover each one.

Builder[edit]

The Builder Creational Pattern is used to separate the construction of a complex object from its representation so that the same construction process can create different objects representations.

Problem 
We want to construct a complex object, however we do not want to have a complex constructor member or one that would need many arguments.
Solution 
Define an intermediate object whose member functions define the desired object part by part before the object is available to the client. Builder Pattern lets us defer the construction of the object until all the options for creation have been specified.
#include <string>
#include <iostream>
 
using namespace std;
 
// "Product"
class Pizza
{
	public:
		void setDough(const string& dough)
		{
			m_dough = dough;
		}
		void setSauce(const string& sauce)
		{
			m_sauce = sauce;
		}
		void setTopping(const string& topping)
		{
			m_topping = topping;
		}
		void open() const
		{
			cout << "Pizza with " << m_dough << " dough, " << m_sauce << " sauce and "
			<< m_topping << " topping. Mmm." << endl;
		}
	private:
		string m_dough;
		string m_sauce;
		string m_topping;
};
 
// "Abstract Builder"
class PizzaBuilder
{
	public:
                virtual ~PizzaBuilder() {}; 
 
		Pizza* getPizza()
		{
			return m_pizza;
		}
		void createNewPizzaProduct()
		{
			m_pizza = new Pizza;
		}
		virtual void buildDough() = 0;
		virtual void buildSauce() = 0;
		virtual void buildTopping() = 0;
	protected:
		Pizza* m_pizza;
};
 
//----------------------------------------------------------------
 
class HawaiianPizzaBuilder : public PizzaBuilder
{
	public:
                virtual ~HawaiianPizzaBuilder() {}; 
 
		virtual void buildDough()
		{
			m_pizza->setDough("cross");
		}
		virtual void buildSauce()
		{
			m_pizza->setSauce("mild");
		}
		virtual void buildTopping()
		{
			m_pizza->setTopping("ham+pineapple");
		}
};
 
class SpicyPizzaBuilder : public PizzaBuilder
{
	public:
                virtual ~SpicyPizzaBuilder() {}; 
 
		virtual void buildDough()
		{
			m_pizza->setDough("pan baked");
		}
		virtual void buildSauce()
		{
			m_pizza->setSauce("hot");
		}
		virtual void buildTopping()
		{
			m_pizza->setTopping("pepperoni+salami");
		}
};
 
//----------------------------------------------------------------
 
class Cook
{
	public:
		void setPizzaBuilder(PizzaBuilder* pb)
		{
			m_pizzaBuilder = pb;
		}
		Pizza* getPizza()
		{
			return m_pizzaBuilder->getPizza();
		}
		void constructPizza()
		{
			m_pizzaBuilder->createNewPizzaProduct();
			m_pizzaBuilder->buildDough();
			m_pizzaBuilder->buildSauce();
			m_pizzaBuilder->buildTopping();
		}
	private:
		PizzaBuilder* m_pizzaBuilder;
};
 
int main()
{
	Cook cook;
	PizzaBuilder* hawaiianPizzaBuilder = new HawaiianPizzaBuilder;
	PizzaBuilder* spicyPizzaBuilder   = new SpicyPizzaBuilder;
 
	cook.setPizzaBuilder(hawaiianPizzaBuilder);
	cook.constructPizza();
 
	Pizza* hawaiian = cook.getPizza();
	hawaiian->open();
 
	cook.setPizzaBuilder(spicyPizzaBuilder);
	cook.constructPizza();
 
	Pizza* spicy = cook.getPizza();
	spicy->open();
 
	delete hawaiianPizzaBuilder;
	delete spicyPizzaBuilder;
	delete hawaiian;  
	delete spicy;     
}

Factory[edit]

Definition: A utility class that creates an instance of a class from a family of derived classes

Abstract Factory[edit]

Definition: A utility class that creates an instance of several families of classes. It can also return a factory for a certain group.


The Factory Design Pattern is useful in a situation that requires the creation of many different types of objects, all derived from a common base type. The Factory Method defines a method for creating the objects, which subclasses can then override to specify the derived type that will be created. Thus, at run time, the Factory Method can be passed a description of a desired object (e.g., a string read from user input) and return a base class pointer to a new instance of that object. The pattern works best when a well-designed interface is used for the base class, so there is no need to cast the returned object.

Problem 
We want to decide at run time what object is to be created based on some configuration or application parameter. When we write the code, we do not know what class should be instantiated.
Solution 
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

In the following example, a factory method is used to create laptop or desktop computer objects at run time.

Let's start by defining Computer, which is an abstract base class (interface) and its derived classes: Laptop and Desktop.

 class Computer
 {
 public:
     virtual void Run() = 0;
     virtual void Stop() = 0;
 
     virtual ~Computer() {}; /* without this, you do not call Laptop or Desktop destructor in this example! */
 };
 class Laptop: public Computer
 {
 public:
     virtual void Run(){mHibernating = false;}; 
     virtual void Stop(){mHibernating = true;}; 
     virtual ~Laptop() {}; /* because we have virtual functions, we need virtual destructor */
 private:
     bool mHibernating; // Whether or not the machine is hibernating
 };
 class Desktop: public Computer
 {
 public:
     virtual void Run(){mOn = true;}; 
     virtual void Stop(){mOn = false;}; 
     virtual ~Desktop() {};
 private:
     bool mOn; // Whether or not the machine has been turned on
 };

The actual ComputerFactory class returns a Computer, given a real world description of the object.

 class ComputerFactory
 {
 public:
     static Computer *NewComputer(const std::string &description)
     {
         if(description == "laptop")
             return new Laptop;
         if(description == "desktop")
             return new Desktop;
         return NULL;
     }
 };

Let's analyze the benefits of this design. First, there is a compilation benefit. If we move the interface Computer into a separate header file with the factory, we can then move the implementation of the NewComputer() function into a separate implementation file. Now the implementation file for NewComputer() is the only one that requires knowledge of the derived classes. Thus, if a change is made to any derived class of Computer, or a new Computer subtype is added, the implementation file for NewComputer() is the only file that needs to be recompiled. Everyone who uses the factory will only care about the interface, which should remain consistent throughout the life of the application.

Also, if there is a need to add a class, and the user is requesting objects through a user interface, no code calling the factory may be required to change to support the additional computer type. The code using the factory would simply pass on the new string to the factory, and allow the factory to handle the new types entirely.

Imagine programming a video game, where you would like to add new types of enemies in the future, each of which has different AI functions and can update differently. By using a factory method, the controller of the program can call to the factory to create the enemies, without any dependency or knowledge of the actual types of enemies. Now, future developers can create new enemies, with new AI controls and new drawing member functions, add it to the factory, and create a level which calls the factory, asking for the enemies by name. Combine this method with an XML description of levels, and developers could create new levels without having to recompile their program. All this, thanks to the separation of creation of objects from the usage of objects.

Another example:

#include <stdexcept>
#include <iostream>
#include <memory>
 
class Pizza {
public:
    virtual int getPrice() const = 0;
    virtual ~Pizza() {};  /* without this, no destructor for derived Pizza's will be called. */ 
};
 
class HamAndMushroomPizza : public Pizza {
public:
    virtual int getPrice() const { return 850; }; 
    virtual ~HamAndMushroomPizza() {}; 
};
 
class DeluxePizza : public Pizza {
public:
    virtual int getPrice() const { return 1050; }; 
    virtual ~DeluxePizza() {};
};
 
class HawaiianPizza : public Pizza {
public:
    virtual int getPrice() const { return 1150; }; 
    virtual ~HawaiianPizza() {}; 
};
 
class PizzaFactory {
public:
    enum PizzaType {
         HamMushroom,
         Deluxe,
         Hawaiian
    };
 
    static Pizza* createPizza(PizzaType pizzaType) {
        switch (pizzaType) {
            case HamMushroom:
                return new HamAndMushroomPizza();
            case Deluxe:
                return new DeluxePizza();
            case Hawaiian:
                return new HawaiianPizza();
        }
        throw "invalid pizza type.";
    }
};
 
/*
 * Create all available pizzas and print their prices
 */
void pizza_information( PizzaFactory::PizzaType pizzatype )
{
	Pizza* pizza = PizzaFactory::createPizza(pizzatype);
	std::cout << "Price of " << pizzatype << " is " << pizza->getPrice() << std::endl;
	delete pizza;
}
 
int main ()
{
	pizza_information( PizzaFactory::HamMushroom );
	pizza_information( PizzaFactory::Deluxe );
	pizza_information( PizzaFactory::Hawaiian );
}

Prototype[edit]

A prototype pattern is used in software development when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. This pattern is used, for example, when the inherent cost of creating a new object in the standard way (e.g., using the new keyword) is prohibitively expensive for a given application.

Implementation: Declare an abstract base class that specifies a pure virtual clone() method. Any class that needs a "polymorphic constructor" capability derives itself from the abstract base class, and implements the clone() operation.

Here the client code first invokes the factory method. This factory method, depending on the parameter, finds out the concrete class. On this concrete class, the clone() method is called and the object is returned by the factory method.

  • This is sample code which is a sample implementation of Prototype method. We have the detailed description of all the components here.
    • Record class, which is a pure virtual class that has a pure virtual method clone().
    • CarRecord, BikeRecord and PersonRecord as concrete implementation of a Record class.
    • An enum RECORD_TYPE_en as one to one mapping of each concrete implementation of Record class.
    • RecordFactory class that has a Factory method CreateRecord(…). This method requires an enum RECORD_TYPE_en as parameter and depending on this parameter it returns the concrete implementation of Record class.
  /**
   * Implementation of Prototype Method 
   **/
  #include <iostream>
  #include <map>
  #include <string>
 
  using namespace std;
 
  enum RECORD_TYPE_en
  {
    CAR,
    BIKE,
    PERSON
  };
 
  /**
   * Record is the base Prototype
   */
 
  class Record
  {
    public :
 
      Record() {}
 
      virtual ~Record() {}
 
      virtual Record* clone()=0;
 
      virtual void print()=0;
  };
 
  /**
   * CarRecord is a Concrete Prototype
   */
 
  class CarRecord : public Record
  {
    private:
      string m_carName;
      int m_ID;
 
    public:
      CarRecord(string carName, int ID)
        : Record()
        , m_carName(carName)
        ,m_ID(ID)
      {
      }
 
      CarRecord(const CarRecord& carRecord)
        : Record(carRecord)//call the base default copy  constructor
      {
        m_carName = carRecord.m_carName;
        m_ID = carRecord.m_ID;
      }
 
      ~CarRecord() {}
 
      Record* clone()
      {
        return new CarRecord(*this);
      }
 
      void print()
      {
        cout << "Car Record" << endl
          << "Name  : " << m_carName << endl
          << "Number: " << m_ID << endl << endl;
      }
  };
 
 
  /**
   * BikeRecord is the Concrete Prototype
   */
 
  class BikeRecord : public Record
  {
    private :
      string m_bikeName;
 
      int m_ID;
 
    public :
      BikeRecord(string bikeName, int ID)
        : Record()
        , m_bikeName(bikeName)
        , m_ID(ID)
      {
      }
 
      BikeRecord(const BikeRecord& bikeRecord)
        : Record(bikeRecord)
      {
        m_bikeName = bikeRecord.m_bikeName;
        m_ID = bikeRecord.m_ID;
      }
 
      ~BikeRecord() {}
 
      Record* clone()
      {
        return new BikeRecord(*this);
      }
 
      void print()
      {
        cout << "Bike Record" << endl
          << "Name  : " << m_bikeName << endl
          << "Number: " << m_ID << endl << endl;
      }
  };
 
 
  /**
   * PersonRecord is the Concrete Prototype
   */
 
  class PersonRecord : public Record
  {
    private :
      string m_personName;
 
      int m_age;
 
    public :
      PersonRecord(string personName, int age)
        : Record()
        , m_personName(personName)
        , m_age(age)
      {
      }
 
      PersonRecord(const PersonRecord& personRecord)
        : Record(personRecord)
      {
        m_personName = personRecord.m_personName;
        m_age = personRecord.m_age;
      }
 
      ~PersonRecord() {}
 
      Record* clone()
      {
        return new PersonRecord(*this);
      }
 
    void print()
    {
      cout << "Person Record" << endl
        << "Name : " << m_personName << endl
        << "Age  : " << m_age << endl << endl ;
    }
  };
 
 
  /**
   * RecordFactory is the client
   */
 
  class RecordFactory
  {
    private :
      map<RECORD_TYPE_en, Record* > m_recordReference;
 
    public :
      RecordFactory()
      {
        m_recordReference[CAR]  = new CarRecord("Ferrari", 5050);
        m_recordReference[BIKE] = new BikeRecord("Yamaha", 2525);
        m_recordReference[PERSON] = new PersonRecord("Tom", 25);
      }
 
      ~RecordFactory()
      {
        delete m_recordReference[CAR];
        delete m_recordReference[BIKE];
        delete m_recordReference[PERSON];
      }
 
      Record* createRecord(RECORD_TYPE_en enType)
      {
        return m_recordReference[enType]->clone();
      }
  };
 
  int main()
  {
    RecordFactory* poRecordFactory = new RecordFactory();
 
    Record* poRecord;
    poRecord = poRecordFactory->createRecord(CAR);
    poRecord->print();
    delete poRecord;
 
    poRecord = poRecordFactory->createRecord(BIKE);
    poRecord->print();
    delete poRecord;
 
    poRecord = poRecordFactory->createRecord(PERSON);
    poRecord->print();
    delete poRecord;
 
    delete poRecordFactory;
    return 0;
  }

Another example:

To implement the pattern, declare an abstract base class that specifies a pure virtual clone() member function. Any class that needs a "polymorphic constructor" capability derives itself from the abstract base class, and implements the clone() operation.

The client, instead of writing code that invokes the new operator on a hard-wired class name, calls the clone() member function on the prototype, calls a factory member function with a parameter designating the particular concrete derived class desired, or invokes the clone() member function through some mechanism provided by another design pattern.

 class CPrototypeMonster
 {
 protected:            
     CString           _name;
 public:
     CPrototypeMonster();
     CPrototypeMonster( const CPrototypeMonster& copy );
     virtual ~CPrototypeMonster();
 
     virtual CPrototypeMonster*    Clone() const=0; // This forces every derived class to provide an overload for this function.
     void        Name( CString name );
     CString    Name() const;
 };
 
 class CGreenMonster : public CPrototypeMonster
 {
 protected: 
     int         _numberOfArms;
     double      _slimeAvailable;
 public:
     CGreenMonster();
     CGreenMonster( const CGreenMonster& copy );
     ~CGreenMonster();
 
     virtual CPrototypeMonster*    Clone() const;
     void  NumberOfArms( int numberOfArms );
     void  SlimeAvailable( double slimeAvailable );
 
     int         NumberOfArms() const;
     double      SlimeAvailable() const;
 };
 
 class CPurpleMonster : public CPrototypeMonster
 {
 protected:
     int         _intensityOfBadBreath;
     double      _lengthOfWhiplikeAntenna;
 public:
     CPurpleMonster();
     CPurpleMonster( const CPurpleMonster& copy );
     ~CPurpleMonster();
 
     virtual CPrototypeMonster*    Clone() const;
 
     void  IntensityOfBadBreath( int intensityOfBadBreath );
     void  LengthOfWhiplikeAntenna( double lengthOfWhiplikeAntenna );
 
     int       IntensityOfBadBreath() const;
     double    LengthOfWhiplikeAntenna() const;
 };
 
 class CBellyMonster : public CPrototypeMonster
 {
 protected:
     double      _roomAvailableInBelly;
 public:
     CBellyMonster();
     CBellyMonster( const CBellyMonster& copy );
     ~CBellyMonster();
 
     virtual CPrototypeMonster*    Clone() const;
 
     void       RoomAvailableInBelly( double roomAvailableInBelly );
     double     RoomAvailableInBelly() const;
 };
 
 CPrototypeMonster* CGreenMonster::Clone() const
 {
     return new CGreenMonster(*this);
 }
 
 CPrototypeMonster* CPurpleMonster::Clone() const
 {
     return new CPurpleMonster(*this);
 }
 
 CPrototypeMonster* CBellyMonster::Clone() const
 {
     return new CBellyMonster(*this);
 }

A client of one of the concrete monster classes only needs a reference (pointer) to a CPrototypeMonster class object to be able to call the ‘Clone’ function and create copies of that object. The function below demonstrates this concept:

 void DoSomeStuffWithAMonster( const CPrototypeMonster* originalMonster )
 {
     CPrototypeMonster* newMonster = originalMonster->Clone();
     ASSERT( newMonster );
 
     newMonster->Name("MyOwnMonster");
     // Add code doing all sorts of cool stuff with the monster.
     delete newMonster;
 }

Now originalMonster can be passed as a pointer to CGreenMonster, CPurpleMonster or CBellyMonster.

Singleton[edit]

The Singleton pattern ensures that a class has only one instance and provides a global point of access to that instance. It is named after the singleton set, which is defined to be a set containing one element. This is useful when exactly one object is needed to coordinate actions across the system.

Check list

  • Define a private static attribute in the "single instance" class.
  • Define a public static accessor function in the class.
  • Do "lazy initialization" (creation on first use) in the accessor function.
  • Define all constructors to be protected or private.
  • Clients may only use the accessor function to manipulate the Singleton.

Let's take a look at how a Singleton differs from other variable types.

Like a global variable, the Singleton exists outside of the scope of any functions. Traditional implementation uses a static member function of the Singleton class, which will create a single instance of the Singleton class on the first call, and forever return that instance. The following code example illustrates the elements of a C++ singleton class, that simply stores a single string.

 class StringSingleton
 {
 public:
     // Some accessor functions for the class, itself
     std::string GetString() const 
     {return mString;}
     void SetString(const std::string &newStr)
     {mString = newStr;}
 
     // The magic function, which allows access to the class from anywhere
     // To get the value of the instance of the class, call:
     //     StringSingleton::Instance().GetString();
     static StringSingleton &Instance()
     {
         // This line only runs once, thus creating the only instance in existence
         static StringSingleton *instance = new StringSingleton;
         // dereferencing the variable here, saves the caller from having to use 
         // the arrow operator, and removes temptation to try and delete the 
         // returned instance.
         return *instance; // always returns the same instance
     }
 
 private: 
     // We need to make some given functions private to finish the definition of the singleton
     StringSingleton(){} // default constructor available only to members or friends of this class
 
     // Note that the next two functions are not given bodies, thus any attempt 
     // to call them implicitly will return as compiler errors. This prevents 
     // accidental copying of the only instance of the class.
     StringSingleton(const StringSingleton &old); // disallow copy constructor
     const StringSingleton &operator=(const StringSingleton &old); //disallow assignment operator
 
     // Note that although this should be allowed, 
     // some compilers may not implement private destructors
     // This prevents others from deleting our one single instance, which was otherwise created on the heap
     ~StringSingleton(){} 
 private: // private data for an instance of this class
     std::string mString;
 };

Variations of Singletons:

Clipboard

To do:
Discussion of Meyers Singleton and any other variations.

Applications of Singleton Class:

One common use of the singleton design pattern is for application configurations. Configurations may need to be accessible globally, and future expansions to the application configurations may be needed. The subset C's closest alternative would be to create a single global struct. This had the lack of clarity as to where this object was instantiated, as well as not guaranteeing the existence of the object.

Take, for example, the situation of another developer using your singleton inside the constructor of their object. Then, yet another developer decides to create an instance of the second class in the global scope. If you had simply used a global variable, the order of linking would then matter. Since your global will be accessed, possibly before main begins executing, there is no definition as to whether the global is initialized, or the constructor of the second class is called first. This behavior can then change with slight modifications to other areas of code, which would change order of global code execution. Such an error can be very hard to debug. But, with use of the singleton, the first time the object is accessed, the object will also be created. You now have an object which will always exist, in relation to being used, and will never exist if never used.

A second common use of this class is in updating old code to work in a new architecture. Since developers may have used globals liberally, moving them into a single class and making it a singleton, can be an intermediary step to bring the program inline to stronger object oriented structure.

Another example:

#include <iostream>
using namespace std;
 
/* Place holder for thread synchronization mutex */
class Mutex
{   /* placeholder for code to create, use, and free a mutex */
};
 
/* Place holder for thread synchronization lock */
class Lock
{   public:
        Lock(Mutex& m) : mutex(m) { /* placeholder code to acquire the mutex */ }
        ~Lock() { /* placeholder code to release the mutex */ }
    private:
        Mutex & mutex;
};
 
class Singleton
{   public:
        static Singleton* GetInstance();
        int a;
        ~Singleton() { cout << "In Destructor" << endl; }
 
    private:
        Singleton(int _a) : a(_a) { cout << "In Constructor" << endl; }
 
 
        static Mutex mutex;
 
        // Not defined, to prevent copying
        Singleton(const Singleton& );
        Singleton& operator =(const Singleton& other);
};
 
Mutex Singleton::mutex;
 
Singleton* Singleton::GetInstance()
{
    Lock lock(mutex);
 
    cout << "Get Instance" << endl;
 
    // Initialized during first access
    static Singleton inst(1);
 
    return &inst;
}
 
int main()
{
    Singleton* singleton = Singleton::GetInstance();
    cout << "The value of the singleton: " << singleton->a << endl;
    return 0;
}

Note:
In the above example, the first call to Singleton::GetInstance will initialize the singleton instance. This example is for illustrative purposes only; for anything but a trivial example program, this code contains errors.