16.1.4. Benefits of Using Factories

16.1.4. Benefits of Using Factories
	16.1. Creational Patterns

[ fromfile: factory.xml id: factorybenefits ]

One of the benefits of factory patterns is that we can manage the created objects in a pool (reusing the ones that can be reused).

Indirect object creation also makes it possible to decide at runtime which class objects to create.
This enables the "plugging in" of replacement classes without requiring changes in the client code.
In src/libs/metadata/abstractmetadataloader.h, there is another example of a factory method that manages singleton instances of MetaDataLoader in such a way that it becomes easy to write programs that can switch between derived metadata loaders without code breakage.

Libraries and Plugins

For a large system, classes are grouped together in libraries when they share some common features, or need to be used together.
Applications generally use classes from several libraries.
Only the public interface of a library class appears in the client code of reusers.
Library designers should be able to change the implementation of a library class without breaking client code.

A plugin is an integrated set of software components that adds specific capabilities to a larger application. An example of a plugin is the Adobe Flash Player, which enables various web browsers to show certain types of videos.
Good plugin support enables the user to customize the functionality of an application.
Many libraries enable the "plugging in" of outside classes by publishing interfaces and documenting how to implement them.
Libraries can facilitate the creation of such plugin classes by providing a factory base class from which specialized factory classes can be derived as needed.

Factory methods 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!

To use polymorphism during initialization, you need Factory methods.
Example 16.8 demonstrates this problem.

Example 16.8. src/ctorpoly/ctorpoly.cpp

#include <iostream>
using namespace std;

class A {
public:
    A() {
        cout << "in A ctor" << endl;
        foo();
    }
    virtual void foo() {
        cout << "A's foo()" << endl;
    }
};

class B: public A {
public:
    B() {
        cout << "in B ctor" << endl;
    }
    void foo() {
        cout << "B's foo()" << endl;
    }
};

class C: public B {
public:
    C() {
        cout << "in C ctor" << endl;
    }

    void foo() {
        cout << "C's foo()" << endl;
    }
};

int main() {
    C* cptr = new C;
    cout << "After construction is complete:" << endl;
    cptr->foo();
    return 0;
}

Its output is given in Example 16.9.

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

src/ctorpoly> ./a.out
in A ctor
A's foo()
in B ctor
in C ctor
After construction is complete:
C's foo()
src/ctorpoly>

Section 22.1 discusses vtables in more detail.


16.1.3. `qApp` and Singleton Pattern		16.1.5. Exercises: Creational Patterns