[Corelinux-public] AbstractFactory design updated

[Frank V. C. <fr...@co...>]

I updated the design because:

The original had

AbstractFactory<>---------->AbstractAllocator<class TypeImpl>

Which constrained the flexibility because in the implementation the
collection, by this definition, would only allow a collection of
homogenous type allocators because

class AbstractFactory
{
public:

	void addAllocator( AbstractAllocator<TYPE NEEDED> * );
};

So, a base class Allocator was inserted which AbstractAllocator derives
from.

This allows the AbstractFactory interface to ignore instantiated
template constraints and focus on managing the Allocators regardless of
type.

The intent is that a AbstractFactory supports creation services for more
than one type, given the GoF example:

class FactoryImplementation
{
public:

	WallPtr	createWall();
	DoorPtr createDoor();
	...
};

which in the new design the declaration would be:

class WallAllocator : public AbstractAllocator<Wall> {}
class DoorAllocator : public AbstractAllocator<Door> {}

class RoomFactory : public AbstractFactory
{
public:

		RoomFactory( void );

	WallPtr	createWall( void );
	DoorPtr	createDoor( void );
};

with an implementation like:

RoomFactory::RoomFactory( void )
{
   addAllocator( new WallAllocator( WallIdentifier ) );
   addAllocator( new DoorAllocator( DoorIdentifier ) );
}

WallPtr RoomFactory::createWall( void )
{
   WallPtr aWall( NULLPTR );
   aWall = getAllocator( WallIdentifier )->createObject();

   CHECK( aWall != NULLPTR );

   return aWall;
}

and so on for Door, Window, etc.

Anyone?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux