Linda Grandell wrote:
In my book, OOP and graphical programming *are* two different things.
I totally agree on this. What I, however, do see as a potential risk here is that the division might lead to students thinking thoughts such as
First of all, I disagree here. Well -- they are. But they really shouldn't be. In my opinion (speaking as a Computer Graphics undergrad), computer graphics are a fundamentally object-oriented task. You're manipulating meshes, polygons, lines or points inside one or more graphical contexts, and each of which share certain attributes (location, color) and methods (translate, draw). This suggests a strong class heirarchy to me, and in fact, when I went about writing my own graphics library last semester, my partner and I took a heavily object-oriented approach (though in C++, not Python). Once we got into the real meat of the assignments, we had a much easier time when we only had to reimplement a few functions, thanks to inheritance, rather than rewriting whole functions from the ground up. Additionally, I think graphics provides a helpful visual metaphor for heirarchical systems, which is, in my opinion, an important part of understanding object orientation. If you have a model heirarchy like: - Model m - SubModel a - SubModel b And you call m.translate(10, 0, 0), the students will see that a and b translate by 10 in x as well. This is metaphorically analagous to changing the impelentation of a method or value of a field in a base class, and having that change reflected in the children. In fact, non-OO graphics systems (I'm thinking OpenGL) basically are object oriented, just without the benefit of living in an OO language. You find, when programming OpenGL, that you do a lot of PushMatrix() and PopMatrix(), which implicitly defines 'objects' in the sense of bits of graphical stuff that move around together. Other begin and end calls work similarly. To finish, I'd say that you should consider what you want the students to get out of the course: if you just want them to have a good time, then programming some procedural stuff with graphics (say, a tron-like game, which I did in Java/AWT/Swing when I was in high school) might be a good idea. If you want them to really learn about object orientation, I think working in an object-oriented modeling system, even if you just end up doing simple 2D stuff, makes a whole lot more sense to me. dsc