> You've certainly given me a mouthful to chew on :~) I was thinking > more in terms of "OOP is about code reuse"
Thats not a good approach to OOP. Code reuse is often as easy to achieve using modules and functions. As Javier said OOP is aboiut "things" - objects. You need to build your whole design around objects communicating with each other, each with some responsibility within the program. The methods implement those responsibilities. Inheritance is a way of abstracting up from specific things to higher level things - the fact that it saves some coding sometimes is a bonus side-effect. In a perfect OO design you should be able to describe (and build) the system using entirely abstract classes, then to make it effective simple implement the sub-classes and plug them in. Its rarely as clean as that but its the goal towards which OO designers strive. > I'm not actually looking for the best approach here - rather just > trying to map a concept I'm familiar with to a new (to me) concept. Thats an OK approach, but the way to map to OOP is to: 1) say what are the objects? 2) can I group the objects into super/sub class chunks 3) what are the responsibilities of each class within my problem 4) build one class, the lowest level one, with no dependencies on the others 5) test it (at the >>> prompt?) 6) build another class with no dependencies on as yet unbuilt classes 7) test it at the >>> prompt 8) test it in in conjunction with the other classes it uses. 9) repeat 6-9 until all classes are built and tested (or enough to implement some part of your application - a "use case"). 10) build the driver program/fuinctoion/object that will pull it all together into an application. And ask questions here as you go :-) Alan G Author of the Learn to Program web tutor http://www.freenetpages.co.uk/hp/alan.gauld _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor