"Kent Johnson" <[EMAIL PROTECTED]> 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. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor