[Tutor] Object-oriented design process
kent37 at tds.net
Sun Nov 27 04:21:07 CET 2005
Alan Gauld wrote:
> I never use commonality of data to define a class. OK I lie, sometimes
> its just convenient to do it that way, but as a principle
> such classes are rarely extensible, they tend to be more like records in
> structured programming speak.
Very few of my classes are ever extended with subclasses.
I don't like to make classes that are just data containers, but I find that when I do make a class like that, I often find some behaviour to go with it. Usually pretty quickly :-) and then I have a real class that is pulling it's weight.
> I do top down design for the class strucure but design and build the
> classes from bottom up. In so doing I will of course discover new
> vclasses that must be slotted ito the structure. But my first cut is
> usually to build a framework of "abstract" classes that work together to
> solve the problem, then I go back filling in the methods from the bottom
> up, and testing each method as each slots into the abstract framework,
> gradually becoming more concrete as it builds.
I guess I have an idea of where I am going, what the eventual pieces will be, but I don't generally build any kind of framework in advance and I don't use many abstract classes.
I think you work at a much larger scale (of program size) than I do, that may be one reason for the different approach. Most of my programs are small or medium size, I'm not sure I have ever worked on a project I would really call large.
> I occasionally refactor at the method level, I very occasionally
> refactor at the class level, but thats rare once I have the abstract
> framework in place.
I refactor constantly. I think of it as building the framework as I go, letting it emerge from the code. When I am done I often have a very highly tuned, application-specific framework, but I didn't imagine it from the start, I evolve it as I develop the overall solution.
> Inwill take the same approach but I will think about the objects, then I
> think about the responsibilities and collaborators (CRC Cards are my
> friends!). Then I write the abstract structure based on the CRCs and
> test it, if it works I go back and fill in the methods. In doing so I
> will discover what data I need.
I sometimes use something like CRC cards. How do you test the abstract structure? With stubs and mock objects?
>> Some of the blocks are classes, others are functions.
> I've built hybrid programs occasionally but in general if a procedural
> approach starts to break I will tend to rework it into pure OOP rather
> than mix paradigms.
I don't have any problem mixing. The procedural parts are usually low-level utility functions or high-level drivers. I just do what seems to work best for each part of the problem.
>> I write unit tests as I go, sometimes test-first, sometimes test-after,
> I like the idea of test first but for me it doesn't work well, but I do
> test on a method by method basis once past the initial framework. (The
> famework is tested class by class since they are only stubs). And
> individual classes get tested at the >>> prompt before veing tried in
> the framework - one of the great joys of Python is interactive testing
> at the >>>.
I do very little of this. For me the problem with testing at the >>> prompt is that the tests aren't captured. By writing the tests as unit tests, they are run repeatedly. When I change the implementation of a class I can re-run the tests and be pretty confident I haven't broken anything. If my original tests were interactive I have to remember how I tested and run them again by hand.
More information about the Tutor