Re: Abstract Method w/o Factory
From: Benjamin M. Stocks (stocksb_at_ieee.org)
Date: 10/17/03
- Next message: Jeff Grigg: "Re: OOD Refactoring RDMS Newbie!"
- Previous message: Otis Bricker: "Re: Right or Wrong Way To Do This?"
- In reply to: H. S. Lahman: "Re: Abstract Method w/o Factory"
- Next in thread: H. S. Lahman: "Re: Abstract Method w/o Factory"
- Reply: H. S. Lahman: "Re: Abstract Method w/o Factory"
- Reply: Daniel T.: "Re: Abstract Method w/o Factory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 17 Oct 2003 09:52:29 -0700
> 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)?
>
That's the problem I'm trying to solve, sort of. The rules for whether
a client is using A or B are well defined, its just a question of how
do I get an instance of A or B to the clients. Many clients will be
dependant on Base because they need A or B.
I guess a bit more background may help explain, this is for an
existing product where clients already depend on Base. I need to break
Base into A and B as we move towards a new platform. So now instead of
simply creating an instance of Base, clients need either A or 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.)
>
I was making an effort to avoid adding a Factory to the product but
that effort may be in vain.
>
> 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).]
>
GetInstance would have to be a static method that applies the well
defined logic (it reads from an EEPROM) to determine if the client
needs A or B.
> 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.]
>
This solution doesn't sit well with the OO part of my gut but I was
trying to avoid adding extra classes to the design. The logic that
selects A or B can only be used to select A or B, its not reusable. So
adding a Factory adds a new class and a new dependancy to every client
that effectively just picks between 2 instances.
Thanks,
Ben
- Next message: Jeff Grigg: "Re: OOD Refactoring RDMS Newbie!"
- Previous message: Otis Bricker: "Re: Right or Wrong Way To Do This?"
- In reply to: H. S. Lahman: "Re: Abstract Method w/o Factory"
- Next in thread: H. S. Lahman: "Re: Abstract Method w/o Factory"
- Reply: H. S. Lahman: "Re: Abstract Method w/o Factory"
- Reply: Daniel T.: "Re: Abstract Method w/o Factory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|