|
From: Frank V. C. <fr...@co...> - 2000-01-27 06:45:49
|
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
|