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