[Tutor] Syntax when using classes question.

[Chris Hengge]

Thanks for the great feedback! I was missing the whole "methods that share
the same data" aspect of a class.. Thats makes them MUCH more clear to
understand.
Thanks for both of you having the patience to help me figure this out =D
Time for me to ditch the classes from my pyForge.py!

On 11/11/06, Alan Gauld <alan.gauld at btinternet.com> wrote:
>
> Chris,
>
> >I guess I'm just lost as to the point of classes... Outside of using
> >them to
> > abstract a collection of methods that have similair roles
>
> Most people get hung up on the data aspect of classes
> and forget that the behaviour(the methods) are actually
> the most important bit. However you have focused so
> much on the methods you haven't noticed the data.
>
> The point of classes is that they encapsulate data and the
> functions that operate on that data. A classs that only has
> functions is just a collection of functions that could sit
> equally well in a module. A class enables you to capture
> state between method calls in data that is local and
> unique to the instance. If there is no shared data between
> the methods then there is little need for a class. (There are
> a few exceptions to that rule but not many). You have to
> think of the methods of a class as being the operations
> on a set of shared data.
>
> Consider a string class; of what use would the strip() method
> be if there was no sequence of characters within the class
> to operate on? or the lower() method etc... Similarly for files.
> If there was no file object then what would you read() or
> write() to?
>
> > But when I group similar methods together
>
> A class is not a group of *similar* methods, it is a set of
> *related* methods - related through the data upon which
> they operate. Think of a class as an object template, a noun.
> Think what things you can do to such an object.
>
> A common, although not always effective, technique for
> identifying classes is to read (or write down if it doesn't
> exist) a description of your problem or program. Underline
> the nouns. Those are your classes. Now pick out the
> verbs and attach them to the nouns. Those are your methods.
> Finally look at the adjectives, those are likely indicators of
> attributes of your classes.
>
> Its simple and not always the best analysis technique but
> its a good way to start.
>
> > promptForge is a bad example,
>
> As I hoped I'd shown a promptForge class would be
> entirely appropriate if it had some data that related to
> the methods. It could present a standard prompt message,
> apply consistent error checking, do datya conersions etc etc.
>
> > people tell me its overkill
>
> OOP can often be overkill, it is frequently abused.
> OOP is great for bigger programs and good for aiding resuse.
> But functions can be just as reusable where no intermediate
> or shared data is involved. If your programs are short there
> is less likeliehood that you will find object useful. As your
> programs get longer objects rapidly become powerful tools.
> But don;t get hung up on them. They are not superior by divine
> right, they are just one more tool in your toolbox.
>
> --
> Alan Gauld
> Author of the Learn to Program web site
> http://www.freenetpages.co.uk/hp/alan.gauld
>
>
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tutor/attachments/20061111/55e3537f/attachment.html