David Bellot wrote:
Hi,
if I consider the Factory Method design pattern, then I should have the
following objects:
This is not really the factory method design pattern as defined by the
GoF. It's just using factory objects.
Object and ObjectFactory which are usually abstract classes
Then for each subclasses like ConcreteObject1 , ConcreteObject2 , .... I
must have a ConcreteObjectF actory1, ConcreteObjectF actory1, ...
What is the benefit using a Factory instead of a constructor to
instantiate a ConcreteObject ?
This is not really a C++ language question. You probably want to ask in
comp.object.
But to give you a common example in C++, you can use different
look-and-feels for GUI elements through a factory:
struct AbstractButton
{
virtual ~AbstractButton () {}
//...
};
struct AbstractFactory
{
virtual ~AbstractFactor y() {}
virtual std::auto_ptr<A bstractButtonCr eateButton() const = 0;
// ...
};
struct SquareButton : AbstractButton { /*...*/ };
struct RoundedButton : AbstractButton { /*...*/ };
struct SquareFactory : AbstractFactory
{
std::auto_ptr<A bstractButtonCr eateButton() const
{
return auto_ptr<Abstra ctButton>( new SquareButton );
}
// ...
};
struct RoundedFactory : AbstractFactory
{
std::auto_ptr<A bstractButtonCr eateButton() const
{
return auto_ptr<Abstra ctButton>( new RoundedButton );
}
// ...
};
struct Dialog
{
Dialog( const AbstractFactory & factory )
{
// ... create and use buttons abstractly, e.g.,
std::auto_ptr<A bstractButtonbu tton = factory.CreateB utton();
// ... now use AbstractButton' s interface here
// and it will apply to either square or rounded buttons
// depending on which factory was passed to this constructor
}
// ...
};
For a more sophisticated implementation of this sort of thing, see
chapters 8 and 9 of _Modern C++ Design_.
Cheers! --M
