Hi Kent, >> point. Classes express behaviour, the data is only there to support >> the behaviour. Thats why methods are polymorphic but not attributes. >> >> So you think of a class having an interface and users extending >> or modifying the behaviour, not the data.
> I think of a class in terms of data attributes *and* behaviour. To me > they are inseparable. To the client of the class, it is the behaviour > that is important, I was talking from the point of view of the client, although the client of one class is likely to be the internals of another! > but inside the class and when designing / discovering classes, > I tend to look at what data I need to represent and solve a > problem and what operations I need on that data I look at data when designing a class - or more specifically a method. I will naturally need some data to build a method, the data I need will be part of the class. And when I look at the totality of the methods I design the data attributes to maximise synergy between methods. But I always define the external behaviour before considering the internal data needevto provide that. > and look for ways to group them together into cohesive classes. 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. > Alan, you and I have very different approaches to OO design > and I don't mean to say my way is right, just an alternative! I don;t think our results are different, (based on the code and ideas I've seen you present here), but our way of verbalising the approach is different. > I tend to design from the bottom up - not exclusively, 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. > but in general I make small parts and combine them to make > larger parts until I have something that does what I want. Me too, but in the context of a preconceived framework. > I refactor constantly as my understanding of a problem > and the solution increase. I occasionally refactor at the method level, I very occasionally refactor at the class level, but thats rare once I have the abstradt framework in place. > This way I always have complete working code for some > section of the problem. I rarely use stubs of any kind. And I have stubs for everything! So there we differ I rarely, if ever. write production methods without first testing the concept with a stub.:-) > To start I will take some small section of the problem > and think about what kind of data and operations on > the data I need to solve it. 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. > For a very simple problem I might just write some functions > to operate on the data. For very simple problems I very rarely use OOP, I tend to find it most helpful when the problem gets beyond a certain size (depends on lamguage etc, but for Python around 50 -100 lines) > 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 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 >>>. > The unit tests give me confidence that I haven's broken anything > in the process. Me too, but at the method level. > It's a very organic process, I sometimes think of it as growing > a program. Yep, I agree. As I said I don;t think our end results are very far apart, we have some minor differences of approach but the focus is still on behaviour from an external point of view and data in the intenal view, I think. And so far as design goes its definitely healthy to compare and contrast approaches. Design is the truly creative bit of software engineering and its always good to know that there is more than one way to do it. And especially important to make that explicit in a tutor group like this! There are no absolutes in this game. 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