Re: class vrs. method

Robert,

Wow. This, plus Michael's contribution, gives me a lot to think about 
and work on. Excellent! Rethinking my methods as little data processing 
machines (which is how I'm currently thinking of classes), along the 
lines you suggest, will clearly help me clean things up.

The idea of putting the messages in show_help into a hash is 
interesting. At first I didn't see the point, but then I see that it 
would split out the data definition from the message generation, and 
this task factoring clearly has advantages.

The CRC abstraction (which I can just do in an outline) is an excellent 
notion. Thanks.

I had hoped this little project, which I expect to rapidly produce a 
tool I'll start using in many ways, would also move my programming 
skills down the road. It's happening. Couldn't ask for more.

I seriously going to try to follow through on all the advice you and 
Michael have give me. It all looks good.

As always, I'm very grateful for this list, and its great generosity.

Tom

Robert Klemme wrote:
> On 07.12.2008 11:58, Tom Cloyd wrote:
>
>> I'm getting it done by writing a number of methods. I keep looking at 
>> other people's programming, and I see many, many classes. Some of 
>> these classes look pointless to me. A mere method would have done the 
>> trick. Why a "class"? I personally feel no need whatsoever to 
>> actually USE one. I'm getting everything done easily and artfully 
>> with mere methods. I simply don't get it - about classes. It looks 
>> like an elegant idea, and in more complex programming I can imagine 
>> why one might use them, but...I've simply cannot find a reason to 
>> bother.
>>
>> I've read a lot about them, but...here's my question:
>>
>> Am I missing something? Can anyone give me a compelling reason to 
>> write fewer methods and more classes?
>
> Interesting question and not easily answered - at least not in 10 words.
>
> For me, the main advantage of OOP over procedural programming is 
> encapsulation - or to name a different term "abstract data types": you 
> combine state (variables) and all the legal operations that can be 
> applied to it - excluding all illegal operations at the same time.  
> This leads to more robust code because, if all classes do only one 
> thing and do that well, you can more easily reuse the code and also 
> the structure is much easier to grasp for someone else (or for you, if 
> you find you need to change something a few months later).
>
> Classes simply give you at least two more dimensions in which to 
> structure your code via encapsulation and inheritance. (Although I 
> personally feel that inheritance is overrated and often overused.)
>
> If you are really interested in the matter and are ready to spend some 
> time (and money) I recommend reading "Object Oriented Software 
> Construction" by Bertrand Meyer (often called "OOSC").  It's a big 
> book but you can read it one concept at a time.  And although he 
> writes mostly about Eiffel (although it is mentioned at most once) he 
> merely talks about all the concepts related to OOP - which happen to 
> be present in Eiffel.  IMHO Eiffel is the language which contains the 
> richest set of OO related features.  BM certainly is among the guys on 
> this planet with the best understanding of what OO is about.
>
>> If anyone's interested, the program to which I referred may be 
>> examined at
>>
>> http://tomcloyd.com/misc/setnet.txt
>
> An easy way to "find" your classes are CRC cards.  "CRC" means "class 
> responsibility collaboration".  Basic idea is to identify things that 
> could be classes, write down their responsibilities and other classes 
> they should collaborate with.
>
> If I were you I would at least create a class Database with all the 
> legal operations (e.g. open or read, close or write, add_relationship 
> etc.).  I did not look closely enough to decide whether I would want 
> to have one database with all the nodes, relationships and links in it 
> but chances are that I would choose that approach.  The reason is, 
> that you want one set of data which is _consistent_.  (Btw, you could 
> also build your database on top of PStore which guarantees some 
> transactional consistency - you won't be able to manipulate the DB via 
> editor though.)
>
> Maybe I would also have a class UserInterface which deals with all the 
> ways a user can interact with your Database.  Looking at method 
> show_help this could be made easier (and more efficient at the same 
> time, although this is probably not important here) by placing all the 
> help messages in a Hash.  I would also try to keep methods much 
> shorter.  For example, you have a big main loop in method main where 
> you do all sorts of things some of which you could refactor to another 
> method or even class (parsing of the command line for example).
>
> Kind regards
>
>     robert
>
>