Arthur wrote:
-----Original Message----- From: John Zelle [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] (319) 352-8360 _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
