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

[Arthur]

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

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.

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

Art