[Tutor] designing POOP

[Alan Gauld]

"Kent Johnson" <kent37 at tds.net> wrote

> Let me say that I don't mean any disrespect for Alan or his 
> approach, I
> just have a different point of view.

Heh, heh! I was waiting for someone to post a message like this.
I'll respond by saying the noun/verb thing is not actually the
method I would normally use (although when all else fails I
do drop back to it as a starter technique). However I have found
it to be a techhnique that woerks well for beginners who don't
know how to get started. Partly because it is fairly mechanistic.

But noun/verb does have some problems and often produces
designs that have too many classes and that do not make
best use of OOP idioms like polymorphism or abstraction.
But for beginners and in small problems it is a good starter.

> Also I will say that converting a procedural program to OO 'just
> because' is not necessarily a good idea. Not every program is 
> improved
> by OOP. In your case, it probably will be though.

This is absolutely true. Too many people approach OOP as
if it were some kind of holy grail that is inherently better
than other styles - it isn't, its just another tool in the toolkit.

> I tend to work from small pieces to larger ones and let the design 
> grow
> from the needs of the code, rather than from considerations of nouns 
> and
> verbs in the spec.

I agree at the micro level and in fact my discussion of
explorers and monsters merging into a figher superclass
hopefully illustrates how that micro level design/code cycle
can generate new features of a design including new
classes/objects. Many OO Design gurus have commented
on the way that OO design tends to cycle between top down
design - identifying core classes - and bottom up design - writing
the lowest building blocks and using that to discover more
about the higher level needs.

OO design is a very organic process compared to procedural
design which tends to bemuch more top down and heirarchical
in nature. In my experience at least.

> accommodate it. Design a little, code a little, repeat...
> http://personalpages.tds.net/~kent37/stories/00003.html

Exactly so.

> The writings of Robert C Martin have taught me a lot about good 
> design
> and agile development. They don't all apply to Python

Martin is very good on Agile, I'm less impressed with his OO writing,
largely because he does tend to see the world through the eyes
of C++ and Java, both of which have a very singular view of OO
which does not always work in other more dynamic OOP
languages (Lisp, Smalltalk, Python, JavaScript etc)

> I don't use the command-line interpreter much, I do a lot more work 
> in
> unit tests. In test-driven development (TDD), if you decide you want 
> a
> Room class, the first thing you do is create a unit test for the 
> class.

For production programming I wholly endorse that approach,
for exploring and inventing code structures (which is mainly
what I use Python for, the results get converted to Java
where we use TDD) I find the interpreter is very useful.

To use TDD effectively you first need to know what you are
trying to do. An example of bad use of TDD can be found in
one of Robert Martins books where he tries to give an example
of pair programming of a bowling game scorer. Unfortunately
because of the haphazard design approach they wind up
with code that is both bloated (it repeats an algorithm twice)
and faulty (one of the algorithm implementations is broken).
Unfortunately they don't detect the fault because the test data
they used missed out all of the cases where the defect is
exhibited... Note it wasn't the test that was broken it was
the limited data set used. And that is one of the big limitations
of TDD, it is only as effective as the test data.

It is important to realize that there is no single way to design
OOP programs. The noun/verb thing is a good way to get
started and often effective when nothing else seems to
be working. But there are plenty of other approaches out
there and books by authors like Booch, Rumbaugh, Jacobsen,
Schaer/Mellor, Coad/Yourdon, Wirfs-Brock and yes, Robert Martin
are all worh reading to see the different approaches available.
The Coad/Nicola OOP book is especially interesting because
it contrasts the same problems in C++ and Smalltalk (which
is conceptually close to python) and shows how the choice
of language can have a big impact on detailed OOP design
decisions.

Once you get experienced in OPP you will not
use the noun/verb te4chnique very often because your brain
will start to think in terms of objects without need of intermediate
tools. In fact when I went back to COBOL for the Y2K bug I
found it hard initially to think procedurally because I'd been
using OOP for so long by then. Nowadays I don;t write so
much code I find I switch between both modes of design
without really thinking too much about it. On small scale
stuff I tend to go procedural but on big problems I tend to
go OOP.

Alan G.