[Tutor] designing POOP

[Alan Gauld]

"bhaaluu" <bhaaluu at gmail.com> wrote 

Let me preface this message by saying that I've never written 
a TAG before - either procedurally nor using OOP. so I don't 
know if the following approach is a good way to go or not. 
However it's where I feel things moving...

> I have a tendancy to think about
> things as actual objects (but probably not OOP
> objects -- more like real objects, like a vase).

But thats the right way to go. The whole point of OOP is 
that you are trying to simulate the real world objects. 
Thats why people who haven't been trained in "classical" 
programming techniqiues usually find OOP much 
easier to pick up than experienced programmers do.
Its logically more sensible to say "move a table" in a 
direction for a distance than to change the x,y 
coordinates explicitly!

> Explorer: has strength & wealth, can carry weapons & food,
> can wear armor, can pick-up treasure, can fight monsters,
> can wound monsters, can defeat monsters, can move from
> room to room.

A good start so Explorer looks like a class with two scalar 
attributes: strength and wealth. Also a number of lists of 
objects - weapons, food, treasure and maybe armor.
Looks like we might have a set of methods to pickUp(object)
and to wear(armor) and maybe some test methods
hasWeapon(weapon), isWearing(armor) etc.
Also we have some methods around fighting, BUT...
We are interested in what we can do TO the objerect 
not what it does to other objects (at least at this point).
So rather than fighting a monster maybe the monster 
can be fought - ie the fight method is a method of monster?
Except....

> Monster: can be anywhere, has Ferocity Factor / Danger Level,
> can fight Explorer, can wound Explorer, can defeat Explorer.

It looks like the same applies to monsters and Explorers. 
So maybe both Monster and Explorer are subclasses of 
a Fighter because they share the same methods.
Now we can have a battle between two fighter objects - and 
this could allow the game to be extended to allow monsters 
to fight monsters and explorers to fight explorers, almost 
for free!

class Fighter(object):
    def fight(self, fighter)    
    def attack(self, weapon)
    def repulse(self, weapon)
    def isKilled(self)
    def currentStrength(self)

Notice that one of the things that seems to come out of this 
is that maybe the strength attribute and the list of weapons 
belongs in the fighter class? Or maybe not if monsters 
don't have weapons - a design decision...

Now we can make a stab at how the fight metjod might work:

def fight(self, fighter):
     weapon = self chooseWeapon()
     fighter.attack(weapon)
     if fighter.isKilled():
        self.strength += fighter.value

And from this we could maybe do the attack method too:

def attack(self,weapon):
      if self.canRepulse(weapon):
         self.repulse(weapon)
      else:
          self.strength -= weapon.value
          if self.strength < 0:
             self.die()

And this reveals some new attributes and methods we 
can add, and also probably some ideas for how to write 
the repulse method too...

And by constantly repeating this cycle of invent a bit, 
write a bit, test a lot we gradually build up the individual 
classes. Remember the >>> prompt is your friend for 
testing these things. Create a few instances of fighters 
and weapons and get them to fight each other using 
the prompt.

When you stop being sure of where to go, go back to 
your text description and look for more clues about 
other objects that might help.

As I say, I don't actually know if the above aproach will 
really work for a TAG but it looks worth a try. But one 
of the beauties of OOP is that each object is a mini 
program that can be played with and experimented 
with at the >>> prompt so you find out what works 
and what doesn't very quickly.

HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld