[Tutor] Object-oriented design process

[Alan Gauld]

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