[Tutor] designing POOP

[bhaaluu]

Greetings,

I've read both Kent's and Alan's approaches to designing a POOP,
and am intrigued with the possibilities of the noun/verb/adjective
technique, but am also sympathetic to the TDD method as well
because it is how I've always programmed. I have noted Alan's
comments on the limitations of TDD, as well as the limitations
of the noun/verb/adjective method of design.

The TDD method is the method used in my tutorial:
Python Programming for the Absolute Beginner 2E. Michael Dawson. 2006.
Dawson uses a very simple Tamagotchi example called Critter Caretaker
to introduce the mechanics of POOP. However, perhaps he is using
the TDD method of "design"?

I'm still experimenting with the noun/verb/adjective design technique,
but I was also itching to get started on something as well, so here is
a first little testing snippet from the testing directory, using the TDD
method. I'm confident that if I am using the terminology incorrectly,
someone will point out the error of my ways. The Tutors are always
saying they really can't help unless they see some code, so this is
a simple adventure game that involves switching a light on and off.
The gameplay isn't all that great, but it is a start. 8^D

#!/user/bin/python
"""
>From the testing laboratory of:
b h a a l u u at g m a i l dot c o m
2008-02-07
"""

import time

CS = "\n"*50

class TestClass1(object):
    """ please give me a better name"""
    def __init__(self):
        """please document me"""
        self.name = ""
        self.answer = ""
        self.strength = 20
        self.wealth = 45
        self.light = 0
        self.tally = 0

def main():
    tc1 = TestClass1() # instance
    tc1.__init__() # invoke method
    print CS
    N1 = tc1.name
    N1 = raw_input(" WHAT IS YOUR NAME, EXPLORER? ")
    # main game loop
    while True:
        print CS
        print (" %s, YOUR STRENGTH IS %d") % (N1, tc1.strength)
        print (" YOU HAVE $%d") % tc1.wealth
        if tc1.light == 0:
            print (" IT IS TOO DARK TO SEE ANYTHING")
        else:
            print (" THE LIGHT'S ON, BUT NO ONE'S HOME")
        print
        print
        A = tc1.answer
        A = raw_input(" WHAT DO YOU WANT TO DO? [Q|L]: ") # main game prompt
        if A.upper() == "Q":
            break
        if A.upper() == "L":
            light = raw_input(" LIGHT? [0|1]: ") # turn the light on and off
            if light == 0 and tc1.light == 0:
                print (" THE LIGHT IS OFF")
                time.sleep(2)
            if tc1.wealth <= 0:
                print
                print (" YOU HAVE NO MONEY")
                time.sleep(2)
            else:
                tc1.light = int(light)
                tc1.wealth -= 15
        else:
            print (" INVALID CHOICE")
            time.sleep(2)
        tc1.tally += 1
        tc1.strength -= 5
        if tc1.strength <= 0:
            print (" YOU DIED....")
            time.sleep(2)
            break
    print
    print (" Final Score:")
    print ("    Tally: %d") % tc1.tally
    print ("   Wealth: $%d") % tc1.wealth
    print (" Strength: %d") % tc1.strength

if __name__ == "__main__":
    main()


On Feb 7, 2008 4:15 AM, Alan Gauld <alan.gauld at btinternet.com> wrote:
> "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.
>
>
>
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>



-- 
b h a a l u u at g m a i l dot c o m
"You assist an evil system most effectively by obeying its
orders and decrees. An evil system never deserves such
allegiance.  Allegiance to it means partaking of the evil.
A good person will resist an evil system with his or her
whole soul." [Mahatma Gandhi]