Creational Patterns

By using creational patterns to manage object creation, we gain flexibility that makes it possible to choose or change the kinds of objects created or used at runtime, and also to manage object deletion automatically. Especially in large software systems, managing the creation of objects is important for flexibility in program design, maintaining a separation between layers of code and ensuring that objects are properly deleted when they are no longer needed.

In C++, a factory is a program component, generally a class, that is responsible for creating objects. The idea of a factory is to separate object creation from object usage.

A factory class generally has a function that obtains dynamic memory for the new object and returns a base class pointer to that object. This approach allows new derived types to be introduced without necessitating changes to the code that uses the created object.

We will discuss several design patterns that use factories and show examples of these design patterns.

When the responsibility for heap object creation is delegated to a virtual function, we call this a Factory method.

By making the factory method pure virtual and writing concrete derived factory classes, this becomes an abstract factory.

By imposing creation rules that prevent direct instantiation of a class, we can force clients to use factory methods to create all instances. When we combine creation rules with a factory method that always returns the same singleton object, this is an example of the Singleton pattern.

Consider two ways of creating a Customer:

Customer* c1 = new Customer(name); Customer* c2 = CustomerFactory::instance()->newCustomer(name)

In the first case, we are hard-coding the class name and calling a constructor directly. The object will be created in memory using the default heap storage. Hard-coded class names in client code can limit the reusability of the code.

In the second case, we create a Customer object indirectly using a factory method called newCustomer(). In fact, newCustomer() is being called on a singleton CustomerFactory instance. CustomerFactory is a singleton because only one instance is available to us, via a static factory method, instance().

16.1.1. Abstract Factory

AbstractFactory, defined in Example 16.1, is a simple class.

Example 16.1. src/libs/dataobjects/abstractfactory.h

The newObject() method is pure virtual, so it must be overridden in derived classes. Example 16.2 shows a concrete class derived from AbstractFactory.

Example 16.2. src/libs/dataobjects/objectfactory.h

ObjectFactory knows how to create a couple of concrete types. Since it is possible for any string to be supplied to newObject(), ObjectFactory handles the case when an unknown class is passed. This is where PropsMap comes into play. ObjectFactory creates a PropsMap if it does not recognize the given class name, as we see in Example 16.3. A PropsMap is a DataObject that holds property values in a hash table, Perl-style.

Example 16.3. src/libs/dataobjects/objectfactory.cpp

newObject() returns the address of an object whose parent is initially set to an ObjectFactory singleton.[1] The parent can be changed later but this ensures that, by default, the object gets deleted with the factory if it's not managed by another object. This is an important measure to prevent memory leaks.

[1] newAddress() also sets the parent to the factory.

16.1.2. Abstract Factories and Libraries

We now discuss two libraries, libdataobjects and libcustomer, each with its own ObjectFactory, as shown in the UML diagram in Figure 16.1.

Figure 16.1. Libraries and factories

CustomerFactory, defined in Example 16.4, extends the functionality of ObjectFactory.

Example 16.4. src/libs/customer/customerfactory.h

CustomerFactory inherits the ability to create Address objects from ObjectFactory. In addition, it knows how to create Customer objects. CustomerFactory overrides and extends the newObject(QString) method to support more types, as shown in Example 16.5.

Example 16.5. src/libs/customer/customerfactory.cpp

For each of the three returned objects the parent is set to be the factory. We see this explicitly in the case of a CustomerList object. If the newCustomer() function is called, it also returns an object that is parented by the factory, as we see in Example 16.6.

Example 16.6. src/libs/customer/customerfactory.cpp

16.1.3. qApp and Singleton Pattern

As we discussed earlier, the Singleton pattern is a specialized factory that is used in situations where at most one instance of a class should be created. We use this pattern to manage a singleton ObjectFactory instance. The class definition in Example 16.7 has two distinctive features that characterize this singleton: a non-public constructor and a public static instance() function.

Example 16.7. src/libs/dataobjects/objectfactory.h

The instance() function, defined in Example 16.8, is our singleton factory. It creates an object if needed, but only the first time that the function is invoked. It always returns a pointer to the same object on subsequent calls.

Example 16.8. src/libs/dataobjects/objectfactory.cpp

For the parent of this object, we set it to qApp. This is a pointer to a singleton instance of a QApplication, which was presumably created in main(). The QApplication instance exists precisely as long as the application is running.

Why not use static for our singleton?

If you make the singleton ObjectFactory a static object instead of a heap object, then children of the factory object will be destroyed after the QApplication is destroyed. Unless there is a compelling reason to the contrary, an application should not do anything after the QApplication has been destroyedincluding object cleanup. Static objects from different files of a multi-file application are destroyed in a linker-dependent order. That order of destruction may cause unintended side-effects (e.g., segmentation faults at termination).

To avoid this problem, you should follow this rule: Each QObject should either be allocated on the stack or be allocated on the heap with another QObject (or qApp) as its parent. This guarantees that there will not be any leftover pieces to be destroyed after the QApplication is destroyed.

If a QObject is allocated on the heap, and its parent is set to qApp, then it is deleted at the "last possible moment." Children of this singleton factory will be deleted just before the factory is deleted.

16.1.4. Creation Rules and friend Functions (What Friends Are Really For)

You can design a class to have a creation rule, such as: All new Customers must be created indirectly through a CustomerFactory. You can enforce this rule by defining only non-public constructors. In particular, make sure that you make the copy constructor and the assignment operator non-public. If you omit them from the class definition, the compiler will supply public versions of these two member functions, thus producing two "loopholes" in your creation rule. For example, this might permit clients to create Customer instances that are not children of your factory (which could lead to memory leaks). It is important to document this rule clearly in your class definition, as we did with the comment in Example 16.9.

Example 16.9. src/libs/customer/customer.h

In Example 16.9, the constructors are protected.[2] CustomerFactory is declared to be a friend class inside Customer. This gives CustomerFactory permission to access the non-public members of Customer. In this way, we have made it impossible for client code to create Customer objects except through the CustomerFactory. In Example 16.10, we have a similar setup with the various Address classes. The base class, Address, is abstract.

[2] This permits us to write derived classes that reuse this constructor.

Example 16.10. src/libs/dataobjects/address.h

In the derived classes, defined in Example 16.11, we have protected the constructors and given friend status to a factory, this time DataObjects:: ObjectFactory. This gives ObjectFactory permission to access the non-public members of UsAddress and CanadaAddress.

Example 16.11. src/libs/dataobjects/address.h

It is now impossible to create Address objects except through the factory or from the derived classes.

16.1.5. Benefits of Using Factories

One of the benefits of factory patterns is that we can ensure that the created objects are destroyed by assigning them parents before returning them. Any object created by ObjectFactory is deleted when the ObjectFactory singleton is destroyed (unless the object's parent is changed).

As processing continues, we normally expect the created objects to acquire more appropriate parents. In fact, we can regard created objects that retain the factory parent as "unclaimed" objects. We can clean up all of the heap memory used by unclaimed objects by iterating through the children of the factory and deleting them.[3]

[3] This is similar to the way that garbage-collected heaps work.

Indirect object creation also makes it possible to decide at runtime which class objects to create. This allows the "plugging in" of replacement classes without requiring changes in the client code. In Section 16.2, we will see an example of a method that makes use of factory objects to create trees of connected, client-defined objects based on the contents of an XML file.

Another benefit of the factory method (or indirect object creation in general) is that you can enforce post-constructor initialization of objects, including the invocation of virtual functions.

Polymorphism from Constructors

An object is not considered "fully constructed" until the constructor has finished executing. An object's vpointer does not point to the correct vtable until the end of the constructor's execution. Therefore, calls to methods of this from the constructor cannot use polymorphism!

Factory methods are required when any polymorphic behavior is needed during object initialization. Example 16.12 demonstrates this problem.

Example 16.12. src/ctorpoly/ctorpoly.cpp

Its output is given in Example 16.13.

Example 16.13. src/ctorpoly/ctorpoly-output.txt

Notice that the wrong version of foo() was called while the new C object was being constructed. You can find more discussion on vtables in Section 23.1.

Exercises: Creational Patterns