Explaining Classes and Objects
So I'm back to helping Bernie Gunn with Python again. He's in charge of the Geokem web site, where lots of scientific information gets collated -- global data basically, much of it geochemical. The HQS is in New Zealand. I salute Bernie, a relatively old guy, for taking a flying leap to our OO paradigm, coming from a strongly procedural school of thought ala Turbo Pascal. He had it all nailed down in TP, and was producing mega amounts of good graphical data. But now he's thinking ahead, about the long term future of his site, and Python looks like a great candidate. Based on my working with Bernie, I think it's helpful to start early with the class/object distinction. He thinks in terms of graphical objects and is using Zelle's graphics.py to re-explore the world of Rectangles etc. That's a good starting point. He's starting to get that it's object.method(arguments), or noun.verb(inputs). He realizes that: rectobj = Rectangle(...) rectobj.setWidth(10) rectobj.draw() is about initializing a new object of the Rectangle class (defined in graphics.py), and using two of its methods, setWidth and draw. Except both these methods are inherited by Rectangle from GraphicsObject through _BBox. Rectangle itself only defines __init__, clone and the private _draw. OO really is a different world. I think it still makes sense to teach the subject historically, even though we *can* start with objects at the same time. In other words, have students relive some of the trauma of moving from the procedural paradigm to the object oriented one -- not to traumatize, but to give the flavor of what "paradigm" even means (including that switching between them may be difficult). Bernie is getting it, and that's testament to Python's transparent syntax (as well as to my dedication in getting my message across; because I think Bernie, and Geokem, are really cool and deserve Python's support). Kirby
Kirby Urner wrote:
Based on my working with Bernie, I think it's helpful to start early with the class/object distinction.... rectobj = Rectangle(...) rectobj.setWidth(10) rectobj.draw()
A useful note here: all programmers are _used_ to using objects: The file for I/O is an OS-defined object (without the nifty syntax in such cases). OO provides (A) a way to define abstractions that behave like the file abstraction yourself, and (B) a way to (at least sometimes) define an abstaction that is "just like that other abstraction except." Until you have A, B doesn't make sense. B is hard to teach in that you need to go slowly -- the changes made by inheritance take a while to "get." --Scott David Daniels Scott.Daniels@Acm.Org
whoops, sent this reply off-list by accident (apologies to Scott) ---- Here's a thought that just jumped into my mind, I don't know if it has any value, but bear me out: I think it probably makes most sense to introduce programming to totally new people in a procedural/structured/whatever you want to call it way. My feeling is that most people who haven't done any programming think of a computer program as a big list of instructions for what to do, and this model should be pretty easy to introduce to them. Now you start to try to do more compliated things, and you have to start accumulating global state so that your many functions can do meaningful things without having to pass loads of arguments around. Pretty soon, depending on the topic, you probably want a way to group global variables together -- the first approach might be to name them similarly, like foo_bar and foo_baz for bar and baz relating to foo. But what if you have two different things of type foo? Now introduce objects as essentially structs. You have a class definition, like: class Foo: bar = someDefault baz = someDefault and just work with that for a while. Now, you are passing around Foo's as arguments to your functions, and you realize that certain functions can only work on Foo's, while others can only work on OtherThing's. Isn't it logical to group your functions in the same way as your variables? Oh, look, thats object-orientation (or the core of it), and you got there all on your own. My experience as a student has been that the best teachers are the ones who give you all but the conclusion, and let you make the final leap yourself. That, I think, makes the knowledge both more likely to stick, and the excercise (which is probably at least somewhat artificial, as most exercies tend to be) more exciting, as you feel like you're making a new contribution to how it all works. Anyway, that's roughly how I had been introduced to OO programming over the years: first BASIC, learning the, well, basics, of program organization with sub's; next, larger scale programs, maybe in C, organizing static members and functions into files; soon structs; then full-on OO with Java (which I loathe), and later Python and C++. Just my $0.02 dsc
Hello Dan, What you have done here is recap the journey from C to object-based C idioms to C++. This is what happened to me in the 80s. It's a very natural progression. Fortunately, we can short-cut it tremendously for students, but it's still a journey worth taking. Monday, June 13, 2005, 2:54:34 PM, you wrote: DC> whoops, sent this reply off-list by accident (apologies to Scott) DC> ---- DC> Here's a thought that just jumped into my mind, I don't know if it has DC> any value, but bear me out: DC> I think it probably makes most sense to introduce programming to totally DC> new people in a procedural/structured/whatever you want to call it way. DC> My feeling is that most people who haven't done any programming think of DC> a computer program as a big list of instructions for what to do, and DC> this model should be pretty easy to introduce to them. DC> Now you start to try to do more compliated things, and you have to start DC> accumulating global state so that your many functions can do meaningful DC> things without having to pass loads of arguments around. Pretty soon, DC> depending on the topic, you probably want a way to group global DC> variables together -- the first approach might be to name them DC> similarly, like foo_bar and foo_baz for bar and baz relating to foo. But DC> what if you have two different things of type foo? DC> Now introduce objects as essentially structs. You have a class DC> definition, like: DC> class Foo: DC> bar = someDefault DC> baz = someDefault DC> and just work with that for a while. Now, you are passing around Foo's DC> as arguments to your functions, and you realize that certain functions DC> can only work on Foo's, while others can only work on OtherThing's. DC> Isn't it logical to group your functions in the same way as your DC> variables? Oh, look, thats object-orientation (or the core of it), and DC> you got there all on your own. DC> My experience as a student has been that the best teachers are the ones DC> who give you all but the conclusion, and let you make the final leap DC> yourself. That, I think, makes the knowledge both more likely to stick, DC> and the excercise (which is probably at least somewhat artificial, as DC> most exercies tend to be) more exciting, as you feel like you're making DC> a new contribution to how it all works. DC> Anyway, that's roughly how I had been introduced to OO programming over DC> the years: first BASIC, learning the, well, basics, of program DC> organization with sub's; next, larger scale programs, maybe in C, DC> organizing static members and functions into files; soon structs; then DC> full-on OO with Java (which I loathe), and later Python and C++. DC> Just my $0.02 DC> dsc DC> _______________________________________________ DC> Edu-sig mailing list DC> Edu-sig@python.org DC> http://mail.python.org/mailman/listinfo/edu-sig -- Best regards, Chuck
Hello Scott, Monday, June 13, 2005, 10:16:12 AM, you wrote: SDD> Kirby Urner wrote:
Based on my working with Bernie, I think it's helpful to start early with the class/object distinction.... rectobj = Rectangle(...) rectobj.setWidth(10) rectobj.draw()
SDD> A useful note here: all programmers are _used_ to using objects: SDD> The file for I/O is an OS-defined object (without the nifty syntax SDD> in such cases). OO provides (A) a way to define abstractions that SDD> behave like the file abstraction yourself, and (B) a way to (at SDD> least sometimes) define an abstaction that is "just like that other SDD> abstraction except." Until you have A, B doesn't make sense. B SDD> is hard to teach in that you need to go slowly -- the changes made SDD> by inheritance take a while to "get."
They're used to using objects in real life, but they're not used to having scaffolding when it's not needed. Case in point: class Hello { public static void main(String[] args) { System.out.println("Hello"); } } What's a beginner supposed to do with this Java program? What's "public?" "static?" "void?" etc. Of course: print 'Hello' they can handle just fine. After a little experience with the interpreter, they can easily pick up methods: words = s.split() They just grok immediately that what follows the dot pertains to what is before it. This is a perfect lead-in to real classes. After having taught C, C++, and Java for years, and mathematics for decades, my 2 cents are: 1) Start with what they know from real life (numbers, simple computations, text processing), in this sense, you begin "procedural" to some degree 2) Python is the best thing I've seen in 30 years of computing for pedogogical and productive purposes. Only when I want speed do I see a need for something else (I'm a C++ guy). As I predicted last week, my current corporate teaching of Python at Symantec is exceeding expectations. I am teaching testers, mostly with no programming experience, Python programming. Man are we smokin'! Man are they going fast! And they are *so* impressed. We just finished our third 4-hour session with list comprehensions and all about dictionaries (every method, including iterators). After modules we'll hit classes. This has been one of the easiest and most rewarding teaching experiences in my career. Even those who have a little Python exposure are amazed when they see truly Pythonic solutions. Python lets you start where people are and naturally proceed to higher-level abstractions. But wait at least until the 4th or 5th day before you do classes :-). -- Best regards, Chuck
On 6/13/05, Chuck Allison <chuck@freshsources.com> wrote: ...
they can handle just fine. After a little experience with the interpreter, they can easily pick up methods:
words = s.split() ...
I believe that "dir( )", when combined with an interactive shell, is the most powerful command in Python. For an example, I made an apparently overly-complicated database to interpret my school's records. When I was trying to figure out which rooms were used by which teachers (in both directions--room by teacher and teacher by room), I started by doing dir(school) to remember what my categories had been, and then eventually figured out what I could loop over and what attribute I wanted. I eventually remembered that school.classes.periods.teachers could be compared to school.classes.periods.rooms in order to come up with what I wanted. This is also how I explore modules with which I am not familiar, and one of the first things I ask my students to do is to import math dir(math)
participants (5)
-
Chuck Allison -
Dan Crosta -
Kirby Urner -
Lloyd Hugh Allen -
Scott David Daniels