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