[Tutor] Object-oriented design process

[Kent Johnson]

Alan Gauld wrote:
> That might be part of the problem, if you think of a class in terms 
> of its data attributes then that is nearly always the wrong starting 
> 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. If you follow that route
> you might find you don't need to write self modifying code, 
> you simply load new classes with a common interface into an 
> existing hook structure.

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, 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 and look for ways to group them together into cohesive classes.

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 tend to design from the bottom up - not exclusively, but in general I make small parts and combine them to make larger parts until I have something that does what I want. I refactor constantly as my understanding of a problem and the solution increase. This way I always have complete working code for some section of the problem. I rarely use stubs of any kind.

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. For a very simple problem I might just write some functions to operate on the data. As I expand into larger parts of the problem I might find that several functions are operating on the same data and decide that they belong in a class. Or it might be clear from the start that I want to create a class around the data.

When one chunk is done to my satisfaction, I take on another, and another. I am creating building blocks, then using the building blocks to create larger blocks. Some of the blocks are classes, others are functions.

I write unit tests as I go, sometimes test-first, sometimes test-after, but always alternating writing code with writing tests so I know the code works and I have a safety net when I need to refactor or make other major changes.

At any time I may discover that I made a bad decision earlier, or realize that there is a better way to structure the code or data. Then I stop and rework until I am happy with what I have. The unit tests give me confidence that I haven's broken anything in the process. It's a very organic process, I sometimes think of it as growing a program.

Kent