| | |
Factory Design pattern implementation
Please support our C++ advertiser: Intel Parallel Studio Home
![]() |
•
•
Join Date: Feb 2005
Posts: 5
Reputation:
Solved Threads: 0
Hi all,
I have an interesting problem for which I already have a solution, but I have a feeling my solution is less than elegant.
I need to create a Factory class which returns an instance of some child of class Foo. Which child is instantiated depends on the value of some integer parameter. So, for example, the following would work well enough:
However, I would need to maintain that switch statement everytime I implement a child class of Foo. So, a better solution, I feel, is to register the child class during static initialization:
The above solution allows me to create a new Foo child class and add it to the factory without having to modify the factory code.
Can I do better? Having to create a getFooXXX() function for each child seems unnecessary. I was thinking of creating a template function getFoo<T>, declared in FooFactory.h, where T would be the child class. This removes the need for separate getFooXXX functions. Any thoughts?
I have an interesting problem for which I already have a solution, but I have a feeling my solution is less than elegant.
I need to create a Factory class which returns an instance of some child of class Foo. Which child is instantiated depends on the value of some integer parameter. So, for example, the following would work well enough:
C++ Syntax (Toggle Plain Text)
class FooFactory { public: Foo* getFooInstance( int id ); } Foo* FooFactory::getFooInstance( int id ) { switch (id) { case 1: return new FooBar(); case 2: return new FooBoo(); default: return NULL; } }
C++ Syntax (Toggle Plain Text)
// FooFactory.h class FooFactory { typedef Foo* (*FooInstantiator)(); typedef std::map<int, FooInstantiator> InstantiatorMap; public: Foo* getFooInstance( int id ); static int registerFooInstantiator(int id, FooInstantiator func); private: static InstantiatorMap m_instantiatorMap; } // FooFactory.cpp // For the sake of brevity, let's just assume we've guaranteed that // m_instantiatorMap already has been constructed. int FooFactory::registerFooInstantiator(int id, FooInstantiator func) { m_instantiatorMap.insert( std::make_pair( id, func ) ); return 1; } // FooBar.h class FooBar : public Foo { ... static int isInitialized; ... } Foo* getFooBar(); // FooBar.cpp int FooBar::isInitialized = FooFactory::registerFooInstantiator( 1, getFooBar ); Foo* getFooBar() { return new FooBar(); }
Can I do better? Having to create a getFooXXX() function for each child seems unnecessary. I was thinking of creating a template function getFoo<T>, declared in FooFactory.h, where T would be the child class. This removes the need for separate getFooXXX functions. Any thoughts?
Last edited by Coding Mage; Feb 10th, 2005 at 1:35 pm. Reason: code tags
•
•
Join Date: Feb 2005
Posts: 17
Reputation:
Solved Threads: 2
You dont specify how you intend to use the factory. That will play a larg part in choosing a Factory pattern to use. So my comments are fairly general.
The motivation behind Factory, is to put the object creation in one place, making maintenance easier & removing dependencies from 'user' code.
IE you expect to change Factory when new Foo sub classes are added. The change can be adding to the switch, or having a heirarchy of Factory classes.
If the Foo heirarchy is fairly stable, then your switch implementation is great.
(I assume that you have left out error checking for simplicity.)
Even if new Foo classes appear fairly often, the code changes are still limited to one place.
Also, if many Foo objects are created, the switch is faster than the map.
In your implementation, you need a new creation function for each class and you also have to provide code which adds the instantiation function/method to the map in Factory. How will you handle errors (eg a duplicate class id)?
In general, i try to avoid passing ids to the object creation code. It can cause maintennace nightmares down the track in anything beyond small projects.
How does user code know which id relates to which sub class?
What would happen (to user code) if a Foo sub class is removed?
And, on a std c++ note.
It is far better to return the newly created objects as auto_ptrs, as these will automatically handle the deletion for you.
eg
auto_ptr<Foo> FooFactory::getFooInstance
The motivation behind Factory, is to put the object creation in one place, making maintenance easier & removing dependencies from 'user' code.
IE you expect to change Factory when new Foo sub classes are added. The change can be adding to the switch, or having a heirarchy of Factory classes.
If the Foo heirarchy is fairly stable, then your switch implementation is great.
(I assume that you have left out error checking for simplicity.)
Even if new Foo classes appear fairly often, the code changes are still limited to one place.
Also, if many Foo objects are created, the switch is faster than the map.
In your implementation, you need a new creation function for each class and you also have to provide code which adds the instantiation function/method to the map in Factory. How will you handle errors (eg a duplicate class id)?
In general, i try to avoid passing ids to the object creation code. It can cause maintennace nightmares down the track in anything beyond small projects.
How does user code know which id relates to which sub class?
What would happen (to user code) if a Foo sub class is removed?
And, on a std c++ note.
It is far better to return the newly created objects as auto_ptrs, as these will automatically handle the deletion for you.
eg
auto_ptr<Foo> FooFactory::getFooInstance
This is sort of a side issue, but I tend to prefer a static method of Foo being the factory, rather than have a seperate class called, in this case, FooFactory. So, the base class would implement
C++ Syntax (Toggle Plain Text)
class Foo { public: <blah blah blah> static Foo* Factory(); // or use the auto_ptr<> if you are a fancy 'I don't use old C-style stuff' bit hugger :-)
•
•
Join Date: Feb 2005
Posts: 17
Reputation:
Solved Threads: 2
•
•
•
•
Originally Posted by Chainsaw
This is sort of a side issue, but I tend to prefer a static method of Foo being the factory, rather than have a seperate class called, in this case, FooFactory. So, the base class would implement
C++ Syntax (Toggle Plain Text)
class Foo { public: <blah blah blah> static Foo* Factory(); // or use the auto_ptr<> if you are a fancy 'I don't use old C-style stuff' bit hugger :-)
Your example saves a class (or class hierarchy).
And, it is much simpler than the Factory pattern.
I have used th same thing in quite a few smallish projects.
However it
- doesnt have the flexibility / power of the abstract factory pattern.
- requires that you have complete control of the Foo interface
As to auto_ptr. It isnt a 'I don't use old C-style stuff''.
Using auto_ptr
- allows you to not worry about deleting things (like not having to close a stream obj).
- makes your code more maintainable
- eliminates hard to fix memory leaks when exceptions are thrown.
•
•
Join Date: Jul 2006
Posts: 1
Reputation:
Solved Threads: 0
•
•
•
•
Originally Posted by Coding Mage
Hi all,
I have an interesting problem for which I already have a solution, but I have a feeling my solution is less than elegant.
I need to create a Factory class which returns an instance of some child of class Foo. Which child is instantiated depends on the value of some integer parameter. So, for example, the following would work well enough:
However, I would need to maintain that switch statement everytime I implement a child class of Foo. So, a better solution, I feel, is to register the child class during static initialization:C++ Syntax (Toggle Plain Text)
class FooFactory { public: Foo* getFooInstance( int id ); } Foo* FooFactory::getFooInstance( int id ) { switch (id) { case 1: return new FooBar(); case 2: return new FooBoo(); default: return NULL; } }
The above solution allows me to create a new Foo child class and add it to the factory without having to modify the factory code.C++ Syntax (Toggle Plain Text)
// FooFactory.h class FooFactory { typedef Foo* (*FooInstantiator)(); typedef std::map<int, FooInstantiator> InstantiatorMap; public: Foo* getFooInstance( int id ); static int registerFooInstantiator(int id, FooInstantiator func); private: static InstantiatorMap m_instantiatorMap; } // FooFactory.cpp // For the sake of brevity, let's just assume we've guaranteed that // m_instantiatorMap already has been constructed. int FooFactory::registerFooInstantiator(int id, FooInstantiator func) { m_instantiatorMap.insert( std::make_pair( id, func ) ); return 1; } // FooBar.h class FooBar : public Foo { ... static int isInitialized; ... } Foo* getFooBar(); // FooBar.cpp int FooBar::isInitialized = FooFactory::registerFooInstantiator( 1, getFooBar ); Foo* getFooBar() { return new FooBar(); }
Can I do better? Having to create a getFooXXX() function for each child seems unnecessary. I was thinking of creating a template function getFoo<T>, declared in FooFactory.h, where T would be the child class. This removes the need for separate getFooXXX functions. Any thoughts?
C++ Syntax (Toggle Plain Text)
typedef InstantiatorMap::value_type InstantiatorMapEntryType; InstantiatorMapEntryType FooFactory::InstantiatorMapEntries[] = { InstantiatorMapEntryType( 1, &FooBar::GetFooBar ), InstantiatorMapEntryType( 2, &FooBar::GetFooBoo ), } InstantiatorMap FooFactory::m_InstantiatorMap( InstantiatorMapEntries, InstantiatorMapEntries + sizeof(InstantiatorMapEntries)/sizeof(InstantiatorMapEntries[0]));
This also has the advantage of giving a concise view of which id goes with which function.
You can also make
getFooInstance static. Then, you never need to instantiate the FooFactory class. ![]() |
Similar Threads
- Design Pattern - Proxy (Computer Science)
- Factory design pattern (C++)
- Virtual constructor (C)
Other Threads in the C++ Forum
- Previous Thread: Extracting folder information with c++
- Next Thread: C++ Mortgage Calculations Help!!
| Thread Tools | Search this Thread |
api array based beginner binary bitmap c++ c/c++ calculator char char* class code coding compile compiler console conversion count data database delete deploy developer dll download dynamic dynamiccharacterarray email encryption error file forms fstream function functions game getline givemetehcodez graph gui homeworkhelp homeworkhelper iamthwee ifstream input int integer java lib linker list loop looping loops map math matrix memory multiple news node number numbertoword output parameter pointer problem program programming project proxy python random read recursion recursive reference rpg sorting string strings struct temperature template text text-file tree url variable vector video visual visualstudio win32 windows winsock word wordfrequency wxwidgets





