[Tutor] designing POOP

[Kent Johnson]

bhaaluu wrote:
> How do you design POOP? What are the guidelines you keep in mind
> to design "good" POOP? Can an absolute beginner learn to design POOP?

I have mostly stayed out of this thread for lack of time and because 
Alan is doing a great job, but I think I will chime in a bit because 
this is an area where Alan and I have very different styles.

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

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.

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 think for me the primary drivers are data structure and functionality. 
For example, maybe I need a way to represent a room. I might start with 
a simple list or tuple and write some code that works with rooms. Soon I 
get tired of having to use subscripts all the time so I make a simple 
container class Room to hold the data. Then I will find bits of 
functionality - functions - that work with the room data; they become 
methods of the Room class.

One piece at a time the code grows. Each new piece of functionality 
imposes new requirements on the design and the design may change to 
accommodate it. Design a little, code a little, repeat...
http://personalpages.tds.net/~kent37/stories/00003.html

Once and Only Once - aka Don't Repeat Yourself - is one of the best 
principles of design. Whenever you are tempted to copy/paste code or 
data, ask yourself how you could change the design to avoid the copying. 
You can discover many useful design techniques by applying DRY. More here:
http://personalpages.tds.net/~kent37/stories/00012.html

Sensitivity to code smells is another good way to discover when your 
design needs to change. Martin Fowler's book Refactoring popularized 
this term. It has a chapter that explains the code smells and points out 
ways to fix them. An abbreviated version is available here:
http://wiki.java.net/bin/view/People/SmellsToRefactorings

The writings of Robert C Martin have taught me a lot about good design 
and agile development. They don't all apply to Python - many design 
patterns that make sense in C++ or Java are not needed in Python - but 
the principles still hold. A lot of his work is available on-line:
http://objectmentor.com/resources/publishedArticles.html

http://objectmentor.com/resources/articles/Principles_and_Patterns.pdf 
might be a good starting point.
http://objectmentor.com/resources/articles/xpepisode.htm attempts to 
give the flavor of agile, test-driven development.

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. 
The test will fail, because the class doesn't exist, so you next write 
the class and make the test pass. Then add another (failing) test for 
the next bit of functionality, then implement it and make the test pass. 
Continue as needed. I have written a little more about this here:
http://personalpages.tds.net/~kent37/stories/00007.html

HTH,
Kent