>> 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. > > Mmmm... that's not really so. If the object's creator meant the score to > be read that way then it would not be 'Tear open the case' but just > 'read the score'. The language with which we describe an action does > matter.
You just invalidated your own argument. Sure, the object's creator may have designated that "the way to read the score is to take these screws out and measure the angle of these gears in ratio to those gears" but what are you really doing here? ...(you are thinking procedurally)... You are really just overlooking the fact that the object is being *read*, meaning that the *object itself returns a representation*. This tearing apart should be abstracted with a method. The meer fact that you say 'tearing open the case' as just another way to say 'read the score' suggests a method called readscore(). You are exactly right. It does not matter with what language you describe an action, because the interface should still remain the same whether you are reading an attribute, or calculating high level summation probabilities to find the score. You are still just vg.readscore() Your particular issue is with the simplicity of the attribute, we don't need a getter method. True. But that in agreement with the concept of OOP. If you decide to pick and choose whether an object does it or whether the developer does it, not only do you have inconsistency in your programming style, but you are no longer OBJECT-Oriented. PS This is one of the big issues that developers have with the win32api. It is procedural in this section, OOP in this section, etc. and more time is spent actually look up these subtle differences to prevent errors than is used in actual coding. A perfect OOP library does not Need a reference book. A good OOP library should only need to propose a pattern. >> 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. >> > > Did we think about REUSABILITY? What if in some other application I want > to USE the score, not just display it? What if I want to display it in a > different form (multiplying it by 100)? Then you are back to our > original options : either check the score directly, define a getter, or > a .... 'stater'(?) which returns the state of the object (in this case > it would be a tuple with only the score in it, a getter in disguise if > you ask me). AFAIK the python way is to just check the score, if later > the object's author changes something he has ways built in in the > language to keep the interface unchanged (yes, I think the score would > be part of the interface, otherwise it would be _score). I completely disagree with your issue on REUSABILITY here. Are you familiar with the concept of subclassing? Or if you wish to ignore the power of OOP, you can just add another method, which is still more realistic and intuitive than directly accessing an internal state variable. Perhaps your major issue here is whether or not score should be public? Alright. Give me one instance in daily usage of any video game where the score of a video game is changed without the video game knowing it. (example - cosmic rays change a bit in the storage of the score and the video game is not aware of it) This concept would allow a violation of a pure OOP VideoGame class, and allow an otherwise private internal state to be made public. PS - for fun. I can think of a more common reason why the score of video games would change without using the actual video game interface. I watched a tv episode of masterminds where the criminal thought up the perfect plan to trick a slot machine by directly accessing the physical chip that determined a winning combination. If the developer of the slot machine had wanted this to be the way that winning combinations are chosen, he should have provided a method which allowed for this. _______________________________________________ Tutor maillist - [email protected] http://mail.python.org/mailman/listinfo/tutor
