Re: Abstract Method w/o Factory
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 10/16/03
- Next message: Chris M. Moore: "Re: One-to-many but also many-to-one"
- Previous message: H. S. Lahman: "Re: Persistent Objects and ObjectLists"
- In reply to: Benjamin M. Stocks: "Abstract Method w/o Factory"
- Next in thread: Benjamin M. Stocks: "Re: Abstract Method w/o Factory"
- Reply: Benjamin M. Stocks: "Re: Abstract Method w/o Factory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 15 Oct 2003 22:56:19 GMT
Responding to Stocks...
> I have a very simple class hierarchy, a base class and two classes
> derived from the base class. The derived classes will redefine a
> single function from the base class.
>
> My problem is in the creation of the derived classes. Needless to say
> I only want the "rest of the world" to depend on the base class, not
> the derived classes. I could use a factory to create a specific
> instance of one of the derived classes, however this is an existing
> application and adding a factory seems like a lot of overhead for what
> should be a simple task of selecting one or the other derived classes.
So what you have is:
? ?
[Client] ----------------- [Base]
A
|
+------+------+
| |
[A] [B]
What is the conditionality and multiplicity of the relationship between
a Client and a Base? Who instantiates that relationship (i.e., who
understands the rules governing whether Client X must be related to an A
or a B)?
It is fairly common for a Factory to instantiate both the instance of
Client and the relationship. Factories are convenient for that because
they isolate the rules and policies of instantiation in one place.
(Typically the rules and policies for who participates in a relationship
are orthogonal to the rules and policies of collaboration between those
participants.)
>
> The (C++ dependant) solution I came up with was to create a
> GetInstance method in the base class that returns a pointer to a base
> class instance and in the implementation file for the base class have
> the GetInstance method perform the same service as a factory would:
> instantiate the appropriate derived class and return it. With this the
> interface to the base class doesn't depend on the derived classes but
> the implementation of the base class depends on the derived classes.
> Make sense?
How does GetInstance know which derived class to instantiate? [My C++
is rusty but I don't see how GetInstance can be invoked without a
specific instance of [Base] in hand (unless it is a static method).]
I don't care for this solution because I think it is highly unlikely
[Base] should be responsible for knowing what sort of leaf class to
create. It is extremely rare (not to mention incestuous) for an object
to be responsible for instantiating instances of the same class. In
most problem spaces someone else (i.e., an object of another class)
understands the rules and policies of instantiation. [This is one of
the uses for Jacobson's "controller" classes.]
*************
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
- Next message: Chris M. Moore: "Re: One-to-many but also many-to-one"
- Previous message: H. S. Lahman: "Re: Persistent Objects and ObjectLists"
- In reply to: Benjamin M. Stocks: "Abstract Method w/o Factory"
- Next in thread: Benjamin M. Stocks: "Re: Abstract Method w/o Factory"
- Reply: Benjamin M. Stocks: "Re: Abstract Method w/o Factory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|