What we do here is utilize a flyweight because of the following assumptions:
Assumption: Rooms have sides with cardinality of [4] Assumption: The side can be either a door or a wall Assumption: The room has at least one (1) door
Unless it is an extreme maze, there is a high probability that there are more walls in a room than doors. By using the Flyweight pattern we can reduce our instance requirements by ( rooms * (sides==walls) ) - 1, for example:
20 rooms with an average of 3 walls each saves 59 wall instances!
The memory savings are the walls * sizeof( wall ) in general and the cycle savings are the new and deletes needed to instantiate and destroy each wall.
Then there is the probable reduction in the locality of reference faults when actually doing something with a wall. But that is beyond the scope of this example.
Anyway, in this example we play with pre-building a room with three (3) walls each. In addition, we utilize the Room interface of setting a side to the room instance.
Refer to ex9 for some of the first order class implementations. You will notice that we reuse almost everything from ex9 except for the Wall (in theory), the MazeFactory for creating the Wall, and the changes in the examp10.cpp source.
A more realistic implementation would have a MazeFactory that is configurable to register allocators so we don't need to expose the application to whether it is using a Flyweight or a true Class instance. Stay tuned, with Builder, Factory Method and a few other patterns we will achieve this and more.