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