[Tutor] OO re-factoring (was Pythonese/Efficiency/Generalesecritique)
alan.gauld at freenet.co.uk
Wed Jun 8 09:21:58 CEST 2005
> 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
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 :-)
Author of the Learn to Program web tutor
More information about the Tutor