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

Original Message: ----------------- From: Dan Crosta dcrosta@sccs.swarthmore.edu Date: Fri, 25 Mar 2005 11:52:37 -0500 (EST) To: edu-sig@python.org Subject: [Edu-sig] Re: Best approach to teaching OOP and graphics 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.
Although we sound like a disagreeable bunch perhaps, I think we're all in general agreement. Graphics programming is very OOPish in most implementations and it makes a whole lot of sense to do graphical programming (GUIs, games, whatever) using objects. The typical think is to export an API in the form of objects with methods and properties. This is how every Pythonic graphics library I'm aware of works. You import a module and you get access to a lot of GUI widgets in the form of objects with methods. You can subclass these widgets or compose them, the way OOPers always do. Typically, we instantiate a window or frame object (some canvas deal) and populate it with buttons, pull-downs and whatever it is. Typically, clicking or mousing over results in events, which our code traps, often by means of callbacks, but maybe by means of the observable/observer design pattern (like Java's). Typically the events themselves are objects (e.g. mouse over events). I just saw a demo of using Python on the Nokia 60-series (a cell phone model). Same thing: a little phone-specific API is imported and appears to the programmer as objects.
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.
Absolutely. I bet we all agree.
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
I'm a little confused why you'd bring up Java/AWT/Swing as your example of doing some procedural stuff with graphics, as this language is highly object oriented in the way you described previously. But here's the thing, the question I think we're asking in this thread: how do we make it clear to students that OOP is NOT *just* about graphical programming? You can write highly object oriented code that has no GUI whatsoever, is invoked only from the command line with switches, maybe runs in the background as a daemon process (like a database) and communicates with the outer world only through some ports over TCP/IP. Is there anything less OOP about such code, which has no graphical shell? No. OOP, as a concept, is conceptually distinguishable from doing GUI or game or graphical programming, even though, as a paradigm, it has become probably the most popular way of doing all of those things. Kirby Other fun things at Pycon 2005: Python used to write a prototype Air Traffic Control system (prototype only in the sense that it's not commercial yet -- not in the sense that the "real" version would be written in something else (it'd stay Python)). Python used in a language teaching engine with Unreal Tournament 2003 as the simulator (showing fictional Iraqi town) and a speech recognizer. Soldiers train on this before going to Iraq. The mission is basically one of "take me to your leader" except it's more "Hi, I'm Joe, this is my team, where's your main guy and could you please give me directions" (all in Arabic, with the detailed directions likewise in Arabic). I did a presentation on Hypertoons that generated some interest. -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

On Fri, 25 Mar 2005, urnerk@qwest.net wrote:
But here's the thing, the question I think we're asking in this thread: how do we make it clear to students that OOP is NOT *just* about graphical programming? You can write highly object oriented code that has no GUI whatsoever, is invoked only from the command line with switches, maybe runs in the background as a daemon process (like a database) and communicates with the outer world only through some ports over TCP/IP. Is there anything less OOP about such code, which has no graphical shell? No. OOP, as a concept, is conceptually distinguishable from doing GUI or game or graphical programming, even though, as a paradigm, it has become probably the most popular way of doing all of those things.
Oh -- I think I misunderstood. I took graphics to mean computer graphics, in the sense of 2D or 3D drawings, modeling, rendering, etc, not GUI design. I've never worked with a non-OO gui toolkit (though I think GTK is, if I'm not mistaken). My point about Java/AWT/Swing was not meant to be about the language -- we just made a big Graphics object, and used its drawline/drawrect/etc functions inside a big ol' while loop. It was a pain, we had to maintain a lot of state that would have been better served by using an OO approach to state maintenance (the two players, their histories, etc) rather than lots of arrays, variables, etc. dsc
participants (2)
-
Dan Crosta
-
urnerk@qwest.net