Re: class vrs. method

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