[Tutor] Object-oriented design process

[Kent Johnson]

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.

Kent
-- 
http://www.kentsjohnson.com