Re: Need help with an odd method
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 03/23/05
- Next message: H. S. Lahman: "Re: Reference Variables"
- Previous message: alex99_at_medcentral.com.au: "Re: Factory Design Pattern and Select Case"
- In reply to: Charles Krug: "Need help with an odd method"
- Next in thread: Charles Krug: "Re: Need help with an odd method"
- Reply: Charles Krug: "Re: Need help with an odd method"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 23 Mar 2005 22:39:16 GMT
Responding to Krug...
> I've a class, call it Thing.
>
> EveryThing has a name and a number, both of which are unique and which
> are "natural" to us from different points in the problem space.
>
> I'd like to have a "Load" method that is equally happy with name or
> number, so that users of the class don't need to concern themselves with
> whether "LoadByName" or "LoadByNumber" might be appropriate.
Basically I agree with McDonagh that this seems to be a job for
overloading a Load method at the OOP level. OTOH, that really depends
on the problem context. For example, you already indicated that Load is
invoked from two different contexts where the identity is viewed
differently. In that case separate interface methods may be quite
reasonable.
That's because at the OOA/D level messages are separated from responses
(methods). The general rule of thumb is that one designs messages based
upon the sender context while the method is designed around intrinsic
receiver behavior. That is, messages are announcements of something
that the sender has done and they reflect the sender's semantics. This
helps decouple the sender implementation from the context of what will
happen in response to the message (i.e., it helps to prevent
implementation dependencies).
The corollary is that one defines messages that the receiver will accept
(i.e., its interface) based upon the needs of clients. In that case
separate interface methods could be justified simply because a given
context might not even know about the other identity view. [This is
much more obvious when one uses state machines for object behaviors.
Then the event name is clearly different than the name of the state
action method that responds to the transition. However, in UML the
class interface is a different model element than the class itself and
that allows one to define messages based on sender context without
affecting class semantics.]
--- Alas, I have a pushback that is somewhat unrelated. This sounds like Load is some sort of initializer that reads data from a DB to initialize the attributes of Thing. If so, I don't think that is a proper responsibility for Thing. (It seems more like a P/R sort of view.) Whoever instantiates Thing should acquire the initialization data beforehand, including the values of both 'name' and 'number'. IOW, the decision is how to access the DB and that should be made by whoever creates the Thing instance. Presumably whoever that is will know what information they have in hand to make that decision. Of course, this may just defer you original issue to invoking the creator. B-) ************* 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.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
- Next message: H. S. Lahman: "Re: Reference Variables"
- Previous message: alex99_at_medcentral.com.au: "Re: Factory Design Pattern and Select Case"
- In reply to: Charles Krug: "Need help with an odd method"
- Next in thread: Charles Krug: "Re: Need help with an odd method"
- Reply: Charles Krug: "Re: Need help with an odd method"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|