Re: class vrs. method

Michael,

Thanks very much. Very lucid and speaking to me right where I am. I get 
it now.

This is the phrase that turned on the light for me "You're building 
excellent accessor methods to global variables (even though you are 
using @instance_variable notation instead of $global_variable notation, 
you only have one namespace in use so they are really just globals)."  
It might help to explain my slowness to grasp things to mention that I 
only just "got" instance variables. I've basically been writing 
fortran/pascal in ruby. It was waaaay eaiser, and I was quite happy, but 
I kept seeing other people doing those strange things which I didn't 
seem to have to do. Puzzling.

In posting here, I just knew someone would be able to nudge me over the 
edge! I was probably too comfortable with what I was doing, which, while 
incomplete at this point, seemed quite acceptable. The idea of building 
in flexibility for the future by using classes is appealing.

So...I'll recode it, now that I see why it's worth the bother.

I truly appreciate your help!

t.

Michael Libby wrote:
> On Sun, Dec 7, 2008 at 4:58 AM, Tom Cloyd <[e-mail]> wrote:
>   
>> Am I missing something? Can anyone give me a compelling reason to write
>> fewer methods and more classes?
>>
>> If anyone's interested, the program to which I referred may be examined at
>>
>> http://tomcloyd.com/misc/setnet.txt
>>     
>
> Tom,
>
> Looks like you're very capable and comfortable with procedural
> programming. Object oriented programming is a different style.
>
> Why would you want to switch to OO style? Ultimately because OO is a
> fundamental design decision in Ruby and your code will just flow more
> easily if you follow that paradigm. In my mind the fact that an object
> system has been tacked onto or designed into every major programming
> language in general use today indicates that OO is either a) being
> forced on us by language designers eager to look "modern" or b)
> actually pretty useful. I'll go with (b).
>
> Specifically in your case:
>
> In your program how can I set up two different sets of nodes,
> relationships, and links at the same time? You're building excellent
> accessor methods to global variables (even though you are using
> @instance_variable notation instead of $global_variable notation, you
> only have one namespace in use so they are really just globals). But I
> can only ever have one set at a time. With object orientation,
> whatever your program does, you could do multiple times by
> instantiating the class as many different times as needed. What if,
> once you finish your main SetNet program, you find you want to write
> another program to build one SetNet based on an existing SetNet?
>
> Also, your add_node and add_relation are the exact same code except
> for the global hash variable they use. While you could build a more
> generalized add_something function and pass the hash as a parameter,
> it would be more readable (and flexible) in the long run to build out
> your base functionality in a Class and then use multiple instances of
> it, or even subclasses if needed, to fine-tune the exact
> functionality.
>
> You also do a lot of message passing. Like manage_log, accepts a
> string that the string uses in a case statement to decide what to
> really do. With objects, that string is not needed. You could just
> have @my_log.open and @my_log.close. You could also then set a log
> filename in your @my_log = MyLog.new("logfile.txt") statement. That
> way you can have multiple log files, or you can decide the name of the
> logfile at the level of the calling code, rather than in your logging
> code. You can still set a default filename in your MyLog class if you
> want.
>
> Of course you could stick to procedural style and split the manage_log
> function in two to enhance readability and avoid passing message
> strings around, but you are then *forced* to stick with one logfile
> for sure, the name of which is stored in a global variable... unless
> you start to rebuild the object system yourself or add yet another
> parameter to each call to indicate which logfile to use.
>
> Well, hope this helps. Just some things to think about.
>
> -Michael
>
>
>