[Tutor] designing POOP

[Kent Johnson]

Tiger12506 wrote:
> vg = VideoGame()
> howmany = rand.randint(0,100)
> for i in range(howmany):
>   vg.buttonpush()
>   print vg.score        #Tear open the case (hope you have a screwdriver)
> 
> OR
> 
> class VideoGame():
>   def __init__(self):
>     self.score = 0
>   def updatedisp():
>     print self.score
>   def buttonpush():
>     self.score += 1
>     self.updatedisp()
> 
> vg = VideoGame()
> howmany = rand.randint(0,100)
> for i in range(howmany):
>   vg.buttonpush()                #Let the videogame display your score 
> however it wishes
> 
> The second way is preferable for many reasons...

Hmm. Not to me. The second version couples the game state with the 
display. I would rather have

- a Game object that maintains the state of the game and has methods to 
manipulate the state

- a Display object that displays the state of the game

- a Controller object that mediates between user interaction, the Game 
and the Display.

Something like:

class Game(object):
   def __init__(self):
     self.score = 0
   def handleSomethingGood(self):
     self.score += 1

class Display(object):
   def showScore(self, score):
     print score

class Controller(object):
   def __init__(self, game, display):
     self.game = game
     self.display = display
   def handleButton(self):
     self.game.handleSomethingGood()
     self.display.showScore(self.game.score)

Now Game.handleSomethingGood() is decoupled from both the display and 
the actual UI event that signals SomethingGood happened.

This is an example of Model-View-Controller architecture (google it). 
Notice that the Game and Display are now reusable (maybe there are both 
GUI and text interfaces to the game, for example, or versions for 
wxPython and PyQt) and testable independently of each other.

A more advanced design might register the Display as an observer of the 
Game score but I don't want to get into that...

Kent