Best approach to teaching OOP and graphics
Dear all, During the last six months, I have given an introductory programming course to high school students using Python. The course covered the fundaments of programming: data types, conditionals, loops, files, exceptions, modules, functions, and so on (no graphics). At the same time I taught Java to another group of high school students, which turned out to be a really "eye-opening" experience; using both languages at the same time really pointed out the advantages of Python. Starting in mid-April, I will give a continuation course to the same students now including OOP concepts and graphics. Based on my positive experience of Python, I will continue using it as the language of instruction. In addition, I am curious about trying out pair-programming in high school settings, and have therefore decided to use this methodology in the course. So far I have come up with two alternatives for how to go about this course: 1) Use PyGame from the very beginning of the course. 2) Cover OOP in the traditional (text-based) manner, using IDLE as in the basic course, and later in the course introduce a GUI module, e.g. AnyGUI, for graphical programming. Using the first approach, graphics could be introduced already during the first lecture, and no distinction would have to be made between non-graphical and graphical programming. This might, on the other hand not be the case with the second approach; in fact, I feel there may be a risk of the students developing an idea of OOP and graphical programming being two different things if they are introduced separately. As an active lurker on the edu-sig list, I therefore decided to present my small "dilemma" here. How do you think OOP and graphics could best be introduced in high schools? Is one of my alternatives OK, or do you have other suggestions? The fact that the students will be working in pairs will hardly affect the choice of teaching approach. Best Python-regards, Linda Grandell Åbo Akademi University Turku, Finland
in fact, I feel there may be a risk of the students developing an idea of OOP and graphical programming being two different things if they are introduced separately.
In my book, OOP and graphical programming *are* two different things. To introduce OOP is to introduce the syntax for classes and forming objects from them e.g. class Foo: pass myobj = Foo() OOP includes ideas of methods & attributes, inheritance, dot notation, operator overloading, method overriding, constructors, static and class methods, various design patterns. You can do all that (or a subset of that) in IDLE if you like. My approach when introducing classes and objects is to emphasize we've been using objects all along, e.g. every list object has all these useful methods by virtue of being of the list type. I do stuff like:
dir([]) # spill the guts of an empty list
or even
dir(1) # spill the guts of the number 1
to show all the "hidden knowledge" any Python object has, owing to the apparatus of built-in types behind it. Then the idea is: as the programmer, you're free to *extend* the tool box with new types (i.e. classes) of your own design. These might have to do with GUI programming in some way, but they certainly don't have to. The first classes I introduce look like this: import random from random import randint class Animal: def __init__(self, name): self.name = name self.state = 'Awake' def sleep(self): print "Zzzzzzz..." self.state = 'Sleeping' def eat(self, food): print "I am eating %s" % (food) def wakeup(self): self.state = 'Awake' def pain(self, location, amount): # <-- student contribution print "My %s hurts!" % (location) self.state = 'In pain' print "It hurts %s!" % (amount) class Dog(Animal): def bark(self, times): print "Woof woof! " * times def jump(self, object): # <-- one of my students wrote this method fallchance = randint(1,10) if fallchance == 10: print "I tripped over a %s!" % (object) self.pain('head', 'a lot') if fallchance != 10: print "I jumped over a %s." % (object) The fact that OOP has proved especially useful when it comes to GUI programming is very true, but then that's all the more reason to not confuse the two. In my high school level Python classes, I've done quite a bit with OOP, and with graphics (POV-Ray especially, with a Python front end for generating scene description language), but to date I have never yet taught any GUI or widget programming. John Zelle's Tkinter-based graphics.py is an attractive option, if I *do* start getting into teaching that stuff. It's easy to use and gives the right idea, but without getting too complicated too quickly. Kirby
I think graphics is a great way to teach programming, because it gives such strong feedback to the students. How about making a small graphics library that has Shape objects. You create a shape object and manipulate it's attributes such as position, color, size, numOfVertices (triangle, square, pentagram), etc. Then you can teach subclassing a shape object, and finally making your own from scratch. PyGame of course is a great environment to build such a thing. -ww
As an active lurker on the edu-sig list, I therefore decided to present my small "dilemma" here. How do you think OOP and graphics could best be introduced in high schools? Is one of my alternatives OK, or do you have other suggestions? The fact that the students will be working in pairs will hardly affect the choice of teaching approach.
Best Python-regards,
Linda Grandell Åbo Akademi University Turku, Finland
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
_________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating
I think graphics is a great way to teach programming, because it gives such strong feedback to the students.
So do I. The students seemed rather happy with the text-based programming in the introductory course... And why shouldn't they? There are so many things to learn about programming itself before one even knows how to realizes if something is missing :) However, as we got closer to the end of the course, comments such as "Could this program be done with graphics?" started to occur. Not often, but still. The post-course survey showed that most students had not missed anything during the course, but some stated that "Graphics would have been fun". So, now I have decided to introduce graphics in one way or another in the continuation course.
How about making a small graphics library that has Shape objects. You create a shape object and manipulate it's attributes such as position, color, size, numOfVertices (triangle, square, pentagram), etc. Then you can teach subclassing a shape object, and finally making your own from scratch. PyGame of course is a great environment to build such a thing.
This sounds like a good idea. I was thinking about using the pygsear package first, mainly because I then would have ready-made material and examples to start from. The course starts in three weeks, so I am not really spoiled with time here. However, your suggestion should not take that long to implement. I will put it on my list of possible alternatives. /Linda
Linda Grandell wrote:
How about making a small graphics library that has Shape objects. You create a shape object and manipulate it's attributes such as position, color, size, numOfVertices (triangle, square, pentagram), etc. Then you can teach subclassing a shape object, and finally making your own from scratch. PyGame of course is a great environment to build such a thing.
This sounds like a good idea. I was thinking about using the pygsear package first, mainly because I then would have ready-made material and examples to start from. The course starts in three weeks, so I am not really spoiled with time here. However, your suggestion should not take that long to implement. I will put it on my list of possible alternatives.
Take a look at VPython. It is the simplest to grasp how to put a few things on the screen; it has a nice small set of 3-D primitives, and a quick intro to get a small display going. Really easier than most 2-D packages I've seen to start with, and you get to roll it around. If you are at PyCon, talk to Kirby about his experiences using it in his classes.
/Linda
-- -- Scott David Daniels Scott.Daniels@Acm.Org
participants (4)
-
Kirby Urner -
Linda Grandell -
Scott David Daniels -
Winston Wolff