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

[John Zelle]

Arthur wrote:
> 
>>-----Original Message-----
>>From: John Zelle [mailto:john.zelle at wartburg.edu]
>>Arthur wrote:
>>I agree that graphics programming is a great, concrete way, to teach
>>about objects. That is the point of my 2D graphics library. VPython is
>>also a great tool. The one caveat I would make here is that many OO
>>designers would say that the approach taken by VPython allowing direct
>>attribute access is not good style. Objects should generally be
>>manipulated through methods, not by twiddling fields. I know this is
>>fairly common in Python, but maybe Vpython is not the best first example
>>of object-oriented design.
> 
> 
> I don't fully grasp what you are saying. Probably mostly because my primary
> understanding of OOP comes directly from Python, and how and to what extent
> Python differs from other approaches is not an area of much clarity for me.
> 
> There are also OOP designers who, I know, would argue that the absence of
> access modifiers in Python is violation of good OOP.  I have heard that
> argument used as a reason why Java is a more appropriate introductory
> language than Python - establishing good OOP habits early.
>

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.

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.

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.

> I would stay out of the argument as to whether access modifiers are
> essential to enterprise level development efforts. 
> 
> But would note that I do have Java in a Nutshell, Second Edition,
> publication date 1996 in my library - because that is where I first started
> in trying to learn programming.   And would say that access modifiers were a
> key impediment to my taking off with Java. I sensed, I think completely
> correctly, that I was approaching a language whose structure was complicated
> by concerns that were no way immediate to my own concerns. If enterprise
> development were to become an interest it would be many moons from my
> starting point, and I would be able to deal with the issues involved at that
> time - a natural ordering in time that a language like Java I don't think
> allows very well.

Agreed here. Access modifiers are another matter. I think intro 
programming are much more natural in languages where I don't have to 
worry about Public, Private, and Protected and the like.

> 
> And I don't think we need to be afraid of teaching Python, exactly as it is,
> as a developed OOP approach. It has grown enough in stature, I think, to
> have proven itself to be another fully legitimate approach - trading
> productivity for what others might consider to be necessary stricture.
> 

I don't disagree with this. And I think there is no reason to avoid 
VPython per se. I'm just suggesting there is an issue to consider in 
that it appears (on its surface) to violate an important OOD principle.

> Which brings us back around to TDD, in some sense.  

Not sure I see the connection here. But I agree with others in this 
thread that TDD is a great way to teach and develop.

-- 
John M. Zelle, Ph.D.             Wartburg College
Professor of Computer Science    Waverly, IA
john.zelle at wartburg.edu          (319) 352-8360