| Topic: |
DEVELOP > c-Plus-Plus |
| User: |
"Boogie El Aceitoso" |
| Date: |
16 Oct 2003 09:22:04 AM |
| Object: |
Trouble with factory pattern |
Hi,
I'd like to have a function factory that returns objects of a class hierarchy.
What's the best way to deal with the fact that different subclasses will have
different constructor arguments?
How do you keep the factory interface as clean as possible? O:-)
TIA
.
|
|
| User: "jeffc" |
|
| Title: Re: Trouble with factory pattern |
16 Oct 2003 10:10:10 AM |
|
|
"Boogie El Aceitoso" <frr149@telefonica.net> wrote in message
news:l4atov0trjv6p3igmc20e8avo6djsukoc4@4ax.com...
Hi,
I'd like to have a function factory that returns objects of a class
hierarchy.
What's the best way to deal with the fact that different subclasses will
have
different constructor arguments?
Well, you either have to supply other constructors for the different
subclasses, or provide default parameters. Of course, you can also have
class hierarchy in your factory design, and have different subclasses of
factories, and create the correct one at startup.
.
|
|
|
| User: "Boogie El Aceitoso" |
|
| Title: Re: Trouble with factory pattern |
16 Oct 2003 11:33:21 AM |
|
|
On Thu, 16 Oct 2003 11:10:10 -0400, "jeffc" <nobody@nowhere.com> wrote:
"Boogie El Aceitoso" <frr149@telefonica.net> wrote in message
news:l4atov0trjv6p3igmc20e8avo6djsukoc4@4ax.com...
Hi,
I'd like to have a function factory that returns objects of a class
hierarchy.
What's the best way to deal with the fact that different subclasses will
have
different constructor arguments?
Well, you either have to supply other constructors for the different
subclasses, or provide default parameters.
It's a hierarchy of classes with an interface similar to std::cout. They print
text on different GUI widgets and each subclass must receive, in it's
constructor, a pointer to the corresponding widget.
I'd like to have a factory function that returns an std::list with objects of
different subclasses.
What's the best way to implement such design? O:-) How can I avoid cluttering
the factory interface?
TIA
.
|
|
|
| User: "WW" |
|
| Title: Re: Trouble with factory pattern |
16 Oct 2003 11:43:21 AM |
|
|
Boogie El Aceitoso wrote:
It's a hierarchy of classes with an interface similar to std::cout.
They print text on different GUI widgets and each subclass must
receive, in it's constructor, a pointer to the corresponding widget.
I'd like to have a factory function that returns an std::list with
objects of different subclasses.
What's the best way to implement such design? O:-) How can I avoid
cluttering the factory interface?
A - make your widgets be inherited from the same base
B- use the prototype pattern
Just two fast ideas... they may not be applicable to your situation.
--
WW aka Attila
.
|
|
|
|
|
|
| User: "Uncle Bob Robert C. Martin" |
|
| Title: Re: Trouble with factory pattern |
21 Oct 2003 08:25:12 PM |
|
|
Boogie El Aceitoso <frr149@telefonica.net> might (or might not) have
written this on (or about) Thu, 16 Oct 2003 16:22:04 +0200, :
Hi,
I'd like to have a function factory that returns objects of a class hierarchy.
What's the best way to deal with the fact that different subclasses will have
different constructor arguments?
How do you keep the factory interface as clean as possible? O:-)
1. Pass some prototype objects to the factory. The factory builds new
objects by cloning the prototypes.
2. Pass the default values for the constructor arguments to the
factory.
3. Create an interface that has primitive 'make' functions for each of
the objects that the factory builds. Pass appropriate derivatives of
this interface to the factory. The factory will use these methods to
build the primitive objects and assemble them.
....
Robert C. Martin | "Uncle Bob"
Object Mentor Inc. | unclebob @ objectmentor . com
501 N. Riverside Dr.| Tel: (800) 338-6716
Suite 206 | Fax: (847) 775-8174 | www.objectmentor.com
| | www.XProgramming.com
Gurnee, IL, | Training and Mentoring | www.junit.org
60031 | OO, XP, Agile, C++, Java, C# | http://fitnesse.org
.
|
|
|
|
| User: "Alf P. Steinbach" |
|
| Title: Re: Trouble with factory pattern |
16 Oct 2003 09:52:50 AM |
|
|
On Thu, 16 Oct 2003 16:22:04 +0200, Boogie El Aceitoso <frr149@telefonica.net> wrote:
I'd like to have a function factory that returns objects of a class hierarchy.
What's the best way to deal with the fact that different subclasses will have
different constructor arguments?
If different subclasses _require_ different constructor arguments this
should be reflected in the factory functions' argument lists. It's not
a C++ question but a design question. If there is a requirement then the
client code will have to supply those arguments, in one form or another.
How do you keep the factory interface as clean as possible? O:-)
That depends on how you're planning to use that, as well as personal
preference (what _you_, and/or your coworkers, regard as "clean").
.
|
|
|
|
| User: "H. S. Lahman" |
|
| Title: Re: Trouble with factory pattern |
18 Oct 2003 02:01:31 PM |
|
|
Responding to El Aceitoso...
I'd like to have a function factory that returns objects of a class hierarchy.
What's the best way to deal with the fact that different subclasses will have
different constructor arguments?
How do you keep the factory interface as clean as possible? O:-)
If the subclasses have different arguments (as opposed to argument
values), then Factory is not going to work well because it depends upon
inclusion polymorphism, which requires a common (abstract) interface.
To deal with your sort of situation the answer lies in parametric
polymorphism. Basically, the <concrete> Factory itself goes and gets
the data that it needs by navigating back to the Context object or to
some sort of specification object. It then uses that data to do the
right thing.
The former is most useful when the Context has all the necessary data,
but only some of it is needed for each constructor. Use an Abstract
Factory pattern and instantiate the relationship between Context and the
relevant concrete Factory. The concrete Factory navigates back to the
Context to get what it needs and then invokes the right constructor.
(The same thing can be done if the necessary data resides in other
objects so long as they can be unambiguously reached via relationships
through the Context object.)
The specification object is useful when the decision data is not readily
available as Context attributes. For example, the subclass to create
may be dictated by an XML string from an external configuration file.
Typically the external configuration data will be placed in a
specification object and a relationship between it and the Factory will
be instantiated along with that to the Context.
A common trick in this situation is to have a flock of private
construction methods in the Factory and a jump table to them that is
indexed by some identity attribute in the specification object. The
private method then parses the rest of the specification data and
invokes the right constructor.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(888)-OOA-PATH
.
|
|
|
|
|
Related Articles |
|
|
