2009/1/29 Tom Cloyd <tomcloyd / comcast.net>:
> Greetings...
>
> I'm continuing my learn-to-write-OO-Ruby journey. Had a recent bad
> experience trying to convert a complex method to a class. The method gets a
> lot of use in my program, and each time it needs to know a lot about the
> environment outside itself. I found myself having to write a ton of instance
> variable data into the class instance to get it to do its job, before I
> called it each time, then read a few more back out to get the results. It
> was awful. What had been a one line call was now about 14 lines of code.
> Ack! I gave up and converted it back to a method, which simply makes more
> sense. I could not find any "class-magic" in this experience - just a lot of
> locked doors.
>
> I now have three questions. I have read a number of people's accounts of
> what classes are and how you build them, etc., etc., and no one seems to
> address these matters at all well (or else I missed it):
>
> 1. HOW do you use a class?
You might want to have a look at all those patterns around - they
should give you an idea how to use them. You could start here:
http://c2.com/cgi-bin/wiki?WelcomeVisitors
> I was assuming that since I couldn't pass data to an instance, after
> creation, I have no option but to write data into its instance vars as
> needed. Sometimes, it seems there simply is no other option.
>
> But, is it approved practice to do something like
>
> junk = MyClass.new( var_1...var_n ).mymethod
That is a rather seldom idiom because usually you want your objects to
live longer. Having said that, there is room for something like that
namely with complex calculations that need a lot of intermediate state
that you want to store in the instance.
> 2. Is it accepted practice to simply create a new instance every time the
> class is needed, thus setting the instance's state once, using it with one
> or more method calls, then moving on to the next new instance? It occurs to
> me that maybe Ruby's garbage collection would sweep the old instance right
> up, knowing it won't be used again, but I don't know.
Yes, that's accepted although one usually tries to keep instances for
longer. In the command pattern you create an instance instead of
invoking a single method:
http://en.wikipedia.org/wiki/Command_patternhttp://c2.com/cgi-bin/wiki?CommandPattern
But even in this case the object lives rather long because the
calculation is typically complex and takes more time.
> My nightmare case is a class which operates on an input record, but
> differently each time, depending upon a number of factors in the environment
> outside the class. I just can't see a graceful way to do this. I'm
> struggling to see why I do OO programming at all in this case.
This smells like State or Strategy Pattern.
http://en.wikipedia.org/wiki/Strategy_patternhttp://en.wikipedia.org/wiki/State_pattern
> 3. Finally, I'm still struggling with the "when do I make something a
> class?" question. I'm surprised that this question is so unimportant or its
> answer so obvious that no one much addresses it. Dave Thomas, in his 3rd ed.
> (I just upgraded, and its really nice!) finally gives two sentences to the
> matter, which is way more than I can find anywhere else: "Whenever you're
> designing OO systems, a good first step is to identify the things you're
> dealing with. Typically each type of thing becomes a class in your final
> program, and the things themselves are instances of these classes."(p. 59)
There are a number of approaches to finding classes. An easy one is
to identify nouns in your description of the problem. Those are
candidate classes and verbs are candidate methods. See the "tutorial"
section for more
http://users.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/
> I've been thinking only in terms of functions, things my program does, and
> not things it works on or with. Both are relevant, clearly, and I'm now out
> on a hunt for "things" that are more than functions. Maybe that will help.
Yes, sounds as if this shift in perspective would help you. Rather ask
"what artifacts do I have in my problem domain" instead of "what needs
to be done"?
> Anyone have any additional advice about "when to make something a class?"
> The principle reasons I see are to achieve scope closure, persistent state,
> and object duplication (multiple instances). Did I miss anything important?
I guess with "scope closure" you mean "encapsulation". Persistence is
not mandatory for OO.
I found this book rather inspiring although it might not be the best
introductory text:
http://archive.eiffel.com/doc/oosc/
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end