}catch(ShapeFactory::BadShapeCreation e) { cout << e.what() << endl;
return 1;
}
for(int i = 0; i < shapes.size(); i++) { shapes[i]->draw();
shapes[i]->erase();
}
purge(shapes); } ///:~
Now the factory method appears in its own class, ShapeFactory, as the virtual create( ). This is a private method which means it cannot be called directly, but it can be overridden. The subclasses of Shape must each create their own subclasses of ShapeFactory and override the create( ) method to create an object of their own type. The actual creation of shapes is performed by calling ShapeFactory::createShape( ), which is a static method that uses the map in ShapeFactory to find the appropriate factory object based on an identifier that you pass it. The factory is immediately used to create the shape object, but you could imagine a more complex problem where the appropriate factory object is returned and then used by the caller to create an object in a more sophisticated way. However, it seems that much of the time you don’t need the intricacies of the polymorphic factory method, and a single static method in the base class (as shown in ShapeFactory1.cpp) will work fine.
Notice that the ShapeFactory must be initialized by loading its map with factory objects, which takes place in the singleton ShapeFactoryInizializer. So to add a new type to this design you must inherit the type, create a factory, and modify ShapeFactoryInizializer so that an instance of your factory is inserted in the map. This extra complexity again suggests the use of a static factory method if you don’t need to create individual factory objects.
Abstract factories
The Abstract Factory pattern looks like the factory objects we’ve seen previously, with not one but several factory methods. Each of the factory methods creates a different kind of object. The idea is that at the point of creation of the factory object, you decide how all the objects created by that factory will be used. The example given in Design Patterns implements portability across various graphical user interfaces (GUIs): you create a factory object appropriate to the GUI that you’re working with, and from then on when you ask it for a menu, button, slider, etc. it will automatically create the appropriate version of that item for the GUI. Thus you’re able to isolate, in one place, the effect of changing from one GUI to another.
As another example suppose you are creating a general-purpose gaming environment and you want to be able to support different types of games. Here’s how it might look using an abstract factory:
//: C09:AbstractFactory.cpp // A gaming environment
Chapter 16: Design Patterns |
441 |
#include <iostream> using namespace std;
class Obstacle { public:
virtual void action() = 0;
};
class Player { public:
virtual void interactWith(Obstacle*) = 0;
};
class Kitty: public Player {
virtual void interactWith(Obstacle* ob) { cout << "Kitty has encountered a "; ob->action();
}
};
class KungFuGuy: public Player {
virtual void interactWith(Obstacle* ob) { cout << "KungFuGuy now battles against a "; ob->action();
}
};
class Puzzle: public Obstacle { public:
void action() { cout << "Puzzle\n"; }
};
class NastyWeapon: public Obstacle { public:
void action() { cout << "NastyWeapon\n"; }
};
// The abstract factory: class GameElementFactory { public:
virtual Player* makePlayer() = 0; virtual Obstacle* makeObstacle() = 0;
};
Chapter 16: Design Patterns |
442 |
// Concrete factories: class KittiesAndPuzzles :
public GameElementFactory { public:
virtual Player* makePlayer() { return new Kitty;
}
virtual Obstacle* makeObstacle() { return new Puzzle;
}
};
class KillAndDismember : public GameElementFactory {
public:
virtual Player* makePlayer() { return new KungFuGuy;
}
virtual Obstacle* makeObstacle() { return new NastyWeapon;
}
};
class GameEnvironment { GameElementFactory* gef; Player* p;
Obstacle* ob; public:
GameEnvironment(GameElementFactory* factory) : gef(factory), p(factory->makePlayer()), ob(factory->makeObstacle()) {}
void play() { p->interactWith(ob);
}
~GameEnvironment() { delete p;
delete ob; delete gef;
}
};
int main() { GameEnvironment
g1(new KittiesAndPuzzles),
Chapter 16: Design Patterns |
443 |