Professional C__ - Marc Gregoire [486]
At first glance, factories seem to lead to complicated designs without clear benefits. It appears that you’re only adding another layer of complexity to the program. Instead of calling createTable() on a FurnitureFactory, you could simply create a new Table object directly. However, factories can actually be quite useful. Instead of creating various objects all over the program, you centralize the object creation for a particular domain. This localization is often a better model of real-world creation of objects.
Another benefit of factories is that you can use them alongside class hierarchies to construct objects without knowing their exact class. As you’ll see in the following example, factories can run parallel to class hierarchies.
The main benefit is that factories abstract the object creation process; you can easily substitute a different factory in your program. Just as you can use polymorphism with the created objects, you can use polymorphism with factories. The following example demonstrates this.
Example: A Car Factory Simulation
In the real world, when you talk about driving a car, you can do so without referring to the specific type of car. You could be discussing a Toyota or a Ford. It doesn’t matter, because both Toyotas and Fords are drivable. Now, suppose that you want a new car. You would then need to specify whether you wanted a Toyota or a Ford, right? Not always. You could just say “I want a car,” and depending on where you were, you would get a specific car. If you said, “I want a car” in a Toyota factory, chances are you’d get a Toyota. (Or you’d get arrested, depending on how you asked). If you said, “I want a car” in a Ford factory, you’d get a Ford.
The same concepts apply to C++ programming. The first concept, of a generic car that’s drivable, is nothing new; it’s standard polymorphism, described in Chapter 3. You could write an abstract Car class that defines a drive() method. Both Toyota and Ford could be subclasses of the Car class, as shown in Figure 29-2.
FIGURE 29-2
Your program could drive Cars without knowing whether they were really Toyotas or Fords. However, with standard object-oriented programming, the one place that you’d need to specify Toyota or Ford is when you create the car. Here, you would need to call the constructor for one or the other. You can’t just say, “I want a car.” However, suppose that you also had a parallel class hierarchy of car factories. The CarFactory superclass could define a virtual buildCar() method. The ToyotaFactory and FordFactory subclasses would override the buildCar() method to build a Toyota or a Ford. Figure 29-3 shows the CarFactory hierarchy.
FIGURE 29-3
Now, suppose that there is one CarFactory object in a program. When code in the program, such as a car dealer, wants a new car, it calls buildCar() on the CarFactory object. Depending on whether that car factory was really a ToyotaFactory or a FordFactory, the code would get either a Toyota or a Ford. Figure 29-4 shows the objects in a car dealer program using a ToyotaFactory.
FIGURE 29-4
Figure 29-5 shows the same program, but with a FordFactory instead of a ToyotaFactory. Note that the CarDealer object and its relationship with the factory stay the same.
FIGURE 29-5
This example demonstrates the main benefit: You can use polymorphism with factories. When you ask the car factory for a car, you might not know whether it’s a Toyota factory or a Ford factory, but either way it will give you a Car that you can drive. This approach leads to easily extensible programs; simply changing the factory instance can allow the program to work on a completely different set of objects and classes.
Implementation of a Factory
One reason for using factories is if the type of the object you want to create depends on some condition. For example, if you are a dealer who needs a car right away, you might want to put your order into the factory that