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 _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor