Re: proper use of classes

David A. Black wrote:
> Hi --
>
> On Thu, 29 Jan 2009, Tom Cloyd wrote:
>
>> 1. HOW do you use a class?
>>
>> 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.
>
> You can pass data to an instance:
>
>   instance.some_method(data)
Uh, yes. I had undervalued this possibility, about which I did know. I 
suppose I could pass in an array of data describing some external state, 
and parse it inside the class. Now, suddenly, I'm seeing a very 
economical way to use classes.
>
>> But, is it approved practice to do something like
>>
>> junk = MyClass.new( var_1...var_n ).mymethod
>>
>> which creates an instance and calls a method which leaves its results 
>> in some instance vars., then simple read the results with...but how? 
>> there's no instance object!
>
> What you've written here is similar to:
>
>   upstring = String.new("David").upcase
>
> or something like that, and it's perfectly legit, though you might
> also want to grab the object separately:
>
>   string = String.new("David")
>   upstring = string.upcase
Yes, I think usually one would.
>
>> (Not that I can find, anyway.) That seems to leave me only with this 
>> possibility:
>>
>> myclass = MyClass.newMyClass.new( var_1...var_n )
>
> I don't quite get that line. What's newMyClass? (Or maybe it's
> garbling again between our machines?)
Yeah, it's garble. Don't know why that happened.
>
>> myclass.mymethod
>> varA = myclass.var_whatever
>> etc....until I have all my results back out of the instance.
>>
>> Compared to a simple method call, this seems designed to make me 
>> crazy quickly. Is there a better way?
Yeah - stuff the variables into an array, and access the array.
>
> I'm not sure I'm following. I guess the short answer is that there's a
> ton of different patterns you can follow, depending on what you need
> to do.
It's clear to me now that if I can pass in an array of data describing 
external state, and can pull it back out by accessing a class instance 
variable containing that array, transformed in some way by its having 
passed through the class instance. Ah...I'm feeling much better now.
>
>> Then, to call the instance again, I have to write new data into its 
>> instance vars. This simply looks like nonsense, unless one really 
>> needs to have the encapsulation that an instance offers. Am I missing 
>> something? Is this just the facts of life when using classes?
The "nonsense" remains, in that so far I'm just employing a method, 
which happens to be formed as a class. There no obvious reason to have 
formed it up as a class. Again I wonder - what's the point of using a 
class? When do we do it? I can think of some applications, but mostly it 
appears that mere methods are fine.
>>
>> 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.
>>
>> 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.
>
> Normally you'd write a class in cases where you want more than one of
> something. I'm not sure that's the case here. What exactly do you mean
> by a class operating on an input record? Or, to go at it a different
> way, what exactly is the flow of events that you want to handle? It
> may be that you could use a class called InputHandler (or whatever),
> and you'd do something like:
>
>   ih = InputHandler.new(filename)
>   fields = ih.parse_into_fields
This looks like a method dressed up as a class. Why do this? I guess it 
could make your root program simpler. Every time you want a new record, 
you tickle the single class instance you have, and it spits out some 
data. But, it quakes like a duck (method), so I have to say that's what 
it is, disguised as a class. In the example, as given to this point, 
there's no reason for the conversion to a class - none that I can see.
>
> A class is a generalization. So if what you're doing isn't general,
> you may not need or want to model it in classes. If you're writing a
> script to parse one particular file, there's quite likely no point
> writing a generalized handler class.
I have to agree. I reached that conclusion over the weekend, with some 
disappointment. I started out some days ago wondering "why classes"? I 
got some decent answers back, but have yet to really find an 
application. Dave Thomas uses an example of a book story inventory 
program, and creates a book class, one instance of which is created for 
every book. So where does that leave us, I wonder? With a running 
inventory program that has 50,000 little book objects bouncing around 
inside? That makes no sense, to me. It certainly is an illustration of 
using classes, but to me in no way illustrates the NECESSITY or even the 
benefit of doing do. I keep thinking I'm missing something that everyone 
else is seeing.

The technology of classes isn't the problem for me. It's the rationale. 
I look at some of gems I use, and I see herds of classes. They make some 
sense as containers for methods, certainly, but modules could do that, 
or some clever naming scheme for set of classes which share some common 
domain.

Maybe it's just an organizational thing. A class is way to create a 
complex thing that looks and acts simple. That, of course, is a terrific 
idea. But, again, mere methods do that quite nicely.

Somehow I'm not quite grasping the heart of the problem I'm having. One 
more try - it's clear why sometimes one uses integers and other times 
floats. I'm trying to get to that level of clarity regarding classes. 
Right now, I appreciate the idea that I might do myClassInstance.a, then 
*.b, , and so on, accessing various methods that are conveniently 
grouped in my ClassInstance. AND that I might want to subclass this so 
as to have a slightly different flavor of it.  It's also clear that I 
might want to hold the state of some domain, while I go off and do other 
things, returning at times to make use of that held state and any 
associated methods. It all sounds like a nice idea.

I need to find some part of my code that cries out for this nice 
concept, and so far I haven't. So far, I have a class that opens some 
files and loads their contents in hashes. Once. And a similar one that 
dumps the hashes back out. Once. A method would the job just as well. 
Making those classes was just an exercise, it now seems.

I just looked over all my methods, in my current project. They're all 
simply blocks of code that get used repeatedly. There's no need to hold 
state. All state resides in the main program. Now, THAT - a main program 
which manages a database modeled on a graph - I'll turn into a class, as 
I might need to have multiple instances running simultaneously, and play 
them off each other. THAT, I think, is the first clear need for a class 
I've yet seen, in my little coding world. The absolute first.

Well, sorry for the digressive nature of my ruminations. I wander 
because I AM a bit lost. Fascinated, but lost. Meanwhile, the code is 
coming along nicely, so I can't really complain too much.

Thanks for your thoughts, David- they WERE helpful. If you have any 
more, please pass them along. Your comments have always been helpful.

Tom

-- 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: [phone]
<< [e-mail] >> (email)
<< TomCloyd.com >> (website) 
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~