[Tutor] designing POOP

[Ricardo Aráoz]

Tiger12506 wrote:
>>> 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"

No, the object's creator designed that "the way to get the score is to
read it".

> 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.

Why? Because you are used to do it that way?

> The meer fact that you say 'tearing open the case' 

YOU are saying it. I'm saying 'read the score'.

> as just another way to say 'read the score' suggests a method called 
> readscore().

Maybe it suggests that to you, not to me. But hey, if it did suggest
readscore() or getscore() then it might also suggest setscore() and then
we might also make sure that score is an integer so we'd better
"declare" it an integer and have an exception if it is ever used to hold
another type, they we might just see the light and start programming Java.

>  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()

Nope, I'm just myVar = vg.score
and there are even ways to make sure that when the user of the class
writes that line he receives a "high level summation probability" just
as if he'd called a method, remember this is Python.

> 
> 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.

Sorry, which concept? According to whom?

> 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.

Says who?
Anyway, I'm no theoretician, I'm a mere programmer. We programmers deal
with practical things so I don't really care if I'm in or out of your
concept of object orientation. So long as my code is maintainable,
extendable, and does what it's supposed to do I'm ok with it, object or
non-object oriented.
Anyway if you wish for better people than me to expose this to you I
suggest you address the python-list (python-list at python.org) and post a
message saying "We should access properties through setters and getters,
otherwise it is not TRUE OOP". I won't take responsibility for any flames.

> 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.

I like good references, I like good documentation. But hey, different
strokes...

>>> 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?

So if I subclass the class it's ok to mess with the property but if I
use the class it's not? Why should that be so? What advantage would that
give me?
If I subclass it, then declare a getter that reads the property and
returns it, then the original class gets changed and I'm in the same
predicament as if I'd used the property straight ahead.

> 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.

An internal state variable? You mean it's 'protected', then it should be
_state instead of state, shouldn't it? And why should it be more
'protected' than that? Aren't we all adults here?

May I suggest you read
http://dirtsimple.org/2004/12/python-is-not-java.html? Specially :
"""
Getters and setters are evil. Evil, evil, I say! Python objects are not
Java beans. Do not write getters and setters. This is what the
’property’ built-in is for. And do not take that to mean that you should
write getters and setters, and then wrap them in ’property’. That means
that until you prove that you need anything more than a simple attribute
access, don’t write getters and setters. They are a waste of CPU time,
but more important, they are a waste of programmer time. Not just for
the people writing the code and tests, but for the people who have to
read and understand them as well.
"""
If you think a property should not be touched then underscore it, that
will tell the user that he messes with it at his own risk. If you want
to check on changes to a property, that can be easily done without using
a setter.

> 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.

Didn't you ever use a "trick" (key combination) to get more lives or
another weapon in Doom?

> (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.

You care too much about "purity". This is a trade, we do what works we
drop what doesn't.
And again, if the property is not considered public it should be
underscored.

> 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. 

We should have told the crook that he should have just subclassed the
slot machine. Then he wouldn't even be a crook, he'd be legal. Don't you
think? ;c)