[Tutor] software design

[Doug Stanfield]

[Katharine Stoner asked:]
>> Does anyone know of a good source on how to design programs
>> before you start programming?  

[and Alan G. answered:]
> Short answer is no. I have a chapter in my book called "Designing
> a solution" but even it is really just some things to think about.
> Its really hard to describe the creative processes involved in
> converting an idea to an algorithm and hence to a program. There
> are a few books on Problem Solving that try to do that but none
> do it well IMHO.

> Going down a level there are a few that describe ways of documenting
> solutions using various notations. But that doesn't help you actually
> come up with a design, just how to write your thoughts down...

Mostly I'm in agreement with Alan.  But I'd like to turn your question
around slightly.  With Python you have a language that gets out of your way
enough that you may be able to start programming before you "do" design.

I don't mean that in the way of taking it to an extreme of randomly entering
code in an editor.  You wouldn't have come to programming and Python without
some idea of something you wanted to make a computer do.  That in itself is
a design.  With many languages you definately need to plan to the extreme to
make headway against the blank slate syndrome.  With Python you have many
tools to get started before your design is fully formed.  That half formed
idea you have can be enough.

My process is very often this:  Start an interpretor session while a text
editor is open in another window.  Think about what the output of the
program needs to be.  Type into the interpreter commands that will produce
that output.  When I've gotten what I want, copy the commands that work into
the editor and create a function structure around it.  Save the file and try
to run it and correct any errors until it does.

This process is as much a design process as sitting down with diagramming
tools and the like.  Its also one that seems best suited to a programmer,
and that Python facilitates instead of impeding like other languages might.
The other more long term process has to do with the evolution of the program
in terms of 'paradigm'.  Mine usually start as simple scripts that
sequentially process something.  I then start pulling functions out to
simplify, adding a if __name__ == '__Main__' to create an importable module.
Finally I'll often pull out code that should go together and start creating
objects.  Python supports this migration from script to functional to object
oriented system in a unique way.

Just to be clear, I think this process eventually requires a bunch more than
the simple version above.  It helps a lot to read a lot of code.  I try to
read everything that comes on c.l.py, especially from the gurus.  This gives
you a basis to start when you are in the interpreter.  You should be aware
of the developments in design patterns, unit testing, and refactoring.  With
this method of coding you are building one or two to throw away.  With
refactoring you don't exactly throw it away, and unit testing, often the
tests come from the original interpreter sessions, makes sure its always
doing what you want.

I guess my main point, start programming and the design will fall into
place.

-Doug-