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

Dan Crosta dcrosta at sccs.swarthmore.edu
Fri Mar 25 17:52:37 CET 2005


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



More information about the Edu-sig mailing list