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@python.org http://mail.python.org/mailman/listinfo/tutor
