What we are working with is right out of the GoF book, the maze factory example with a couple of twists:
A. We are not creating the Maze game, just a AbstractFactory.
B. The behavior of the MapSite objects are not fully defined. I forced some assertion semantics on some things, but I left it mostly alone.
C. Sometimes something happens when you enter it, others are undefined.
And a couple of notes where the libcorelinux differs from the pattern example in the book:
1. We have included a Singleton type template in the library. It's success depends on the adherence to protocol that you won't instantiate the object the singleton guards. The constructor for the Singleton will guard against multiple instantiations of the same type (Singleton<Foo> aFoo; Singleton<Foo> bFoo; the bFoo will assert).
2. The CoreLinux++ implementation of AbstractFactory relies on a collection [0..n] of AbstractAllocators. This was to preserve the abstraction of the factory down to the problem domain; in this case the Maze example.
3. We defered the binding of Key and collection in AbstractFactory so that the developer will have the ultimate flexibility in their designs.
4. In libcorelinux++ we define a macro CORELINUX_DEFAULT_ALLOCATOR which is used when you just want the new and delete memory management. This increases ease of use, and with the addition of instrumentation in both the Allocator base and AbstractFactory, it is easy to monitor which allocations are called more frequently.
Of course, any suggestions to make it better are welcome. Anyway:
We use the corelinux::Identifier as a base for NameIdentifier, we will use this to bind allocators instead of some numbering scheme. They are also self describing in the example.
We will use the CORELINUX_DEFAULT_ALLOCATOR,