[Edu-sig] Re: Best approach to teaching OOP and graphics

[Dethe Elza]

On 27-Mar-05, at 2:04 PM, John Zelle wrote:
> I am not really talking about access modifiers. I am simply saying 
> that most OOD guidelines would suggest that an object should be 
> modified by calling its methods, not by setting fields. In VPython one 
> does mySphere.color = color.red as opposed to something like: 
> mySphere.setColor(color.red)
>
> There is a good reason for these traditional guidelines, that is to 
> make the abstraction you are defining independent of its 
> implementation. Down the road, I might want to change the internal 
> representation of color, or remove or rename the color instance 
> variable. If existing code exploits this internal feature of a class, 
> then changing the implementation may break code that uses it. So this 
> is bad design --- in most languages.
>
> And yet, this is common in Python. Why? Because of Python's dynamic 
> nature I can still change the implementation should I choose to and I 
> can preserve the old abstraction (interface) using getAttr and setAttr 
> magic. I can't do that in most other languages, which is why they tend 
> to use getter and setter methods.

Or more recently (and cleanly) by using properties (new style classes 
only).

The *only* reason that other languages promote the use of method calls 
over direct property access is because they don't have properties.  
Without properties it is very
difficult to go in and modify the implementation without changing the 
interface if you start by using attributes, but in Python that problem 
just doesn't exist.

There are still times when you don't want to expose attributes 
directly, but getters and setters don't help you there either.  For 
example, if both myObj.x and myObj.y must be changed in synch to stay 
valid, then they should be set via myObj.setXandY(x,y) not myObj.x = 
newX, myObj.y = newY.  But this is a design problem not a language 
problem.

> What I am saying, is that if you are teaching programming for the 
> purpose of having students learn general principles of programming, 
> implementation independence is an important concept. But you probably 
> don't want to get into setAttr and getAttr right away. That means you 
> probably want examples of OOD that use methods to change objects. 
> Otherwise you _seem_ to be providing them examples that contradict 
> good practice that you tell them about.

No, don't get into setAttr and getAttr right away!  Avoid them if you 
can.  Go with new style classes (those that inherit from object), and 
teach them to use attributes to begin with (simple), and properties 
when needed.

> If you are just teaching programming as a road to learning some other 
> subject in depth, then I don't see much problem here. But I wouldn't 
> want my students to apply the Python style in, say, Java.

Nor Java style in Python.  Phillip Eby has a longer (and quite good) 
piece on this: http://dirtsimple.org/2004/12/python-is-not-java.html.

--Dethe


"No lesson seems to be so deeply inculcated by experience of life as 
that you should never trust experts.  If you believe doctors, nothing 
is wholesome; if you believe theologians, nothing is innocent; if you 
believe soldiers, nothing is safe."

         --Lord Salisbury, 19th century British prime minister
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2488 bytes
Desc: not available
Url : http://mail.python.org/pipermail/edu-sig/attachments/20050327/cb8c4265/smime-0001.bin