[Tutor] designing POOP

[Tiger12506]

> "bhaaluu" <bhaaluu at gmail.com> wrote
>
>> States, getters-setters, direct access.......
>> I'm still in toilet-training here/ 8^D
>> Can you provide some simple examples that
>> illustrate exactly what and why there is any
>> contention at all?

One clear example I can think of that shows the views is this:

Imagine you have a video game. You model it with a class.

class VideoGame:
  pass

But this video game will up your score if you hit this a particular button, 
which means that it needs to a) keep track of its score b) know what to do 
when the button is pushed

class VideoGame:
  def __init__(self):
    self.score = 0
  def buttonpush(self):
    self.score += 1

This is all fine and dandy, but the video game is pretty worthless unless it 
can show us what the score is. There are two ways to go about this. A) Give 
the video game a display which it updates, or B) Tear open the case of the 
video game and look at the actual gears that increment the score to read it. 
(imagine it's an old, old game - work with me here!)
So, to print, you can...

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...
A) The game designer decides to change the display, you don't have to change 
any code that uses the class
B) Clearly, tearing open a videogame is pretty low-level from an object 
perspective. This is what Alan is saying with OOP purism.

Now. Alan's suggestion to have a state method is like... having a sticker on 
the side of the video game that constantly changes to show the internal 
state of the machine. (yeah yeah, stickers change, sure...) Anyway, This is 
very nice from a debugging standpoint, where you find out that the game does 
something incredibly weird, (like after 2**16 buttonpushes it jumps to 
negative numbers), so that you can watch exactly what happens inside the 
machine without tearing it apart. There are a few drawbacks though.
As soon as you change the internal mechanism, the sticker is at a loss 
because it can't tell you the state anymore! So every time you change the 
internals, you have to change the sticker on the outside to reflect that 
change. This is what Kent is trying to say here about the lack of advantage 
to a state method. However, the advantage of pure OOP here is that if the 
videogame model is designed correctly, never would you have to change the 
actual display if you changed how the score was calculated.

Well, I don't know if this whole email was of use, but it makes the crux of 
the argument make sense to me.