[Edu-sig] Explaining Classes and Objects
lac at strakt.com
Tue Jun 14 01:40:30 CEST 2005
It may be that I have the joy of teaching 10 year olds, and you have to
deal with more experienced folk.
raise "that was stupid!" #translate that into your language
has enormous 'teacher-as-hero' value around here.
I know all the arguments as to why string exceptions should be removed from python.
I even agree with them.
raise 'you are an idiot!'
in some circles has its own sort of charm ....
ps -- i am not entirely sold on oo programming. clearly it is the correct way to model
certain problems, but a more functional approach seems better suited to other kinds.
I think teaching TDD is more important than OO these days. Am I only reflecting
my own loves and predjudice?
In a message of Mon, 13 Jun 2005 09:13:55 PDT, "Kirby Urner" writes:
>> In a message of Sun, 12 Jun 2005 22:08:50 PDT, "Kirby Urner" writes:
>> >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 traum
>> >of moving from the procedural paradigm to the object oriented one --
>> >not to traumatize, but to give the flavor of what "paradigm" even mean
>> >(including that switching between them may be difficult).
>> This may make sense for people who already know procedureal programming
>> but I don't think that it is a good idea for the rest of the world. I
>> think that you need to learn about exception handling _early_ ... say
>> right after you learn how to write a loop, and unit testing, and test
>> driven design from the moment you get out of the 'how to play with the
>> interpreter' stage.
>The average beginner isn't going to know any programming, so why not star
>with class/object right from the top?
>Yet the procedural model requires less setup I think, less background.
>There's no "class hierarchy" to discuss.
>This is where the parallel experience with math, in algebra, will help, a
>in Python we have top-level functions, and procedural programming is main
>just organizing the flow in terms of a main procedure branching to and
>returning from numerous subprocedures e.g.:
> vars = sub1(args)
> vars = sub2(vars)
> vars = sub3(vars)
> return vars
>Procedural code starts as simply as:
> return x*x
>My approach is to start with a lot of a rule-based numeric sequences (the
>above generates square numbers): triangular numbers, Fibonacci numbers,
>other polyhedral numbers. This means writing a bunch of free-standing
>functions. But then suddenly you need one to call the other, i.e. when
>doing tetrahedral numbers, you need to stack consecutive triangles:
> return n*(n+1)//2
> sum = 0
> for i in range(n):
> sum += tri(i) # <-- function calling function
> return sum
>There was an earlier paradigm shift for the first users of procedural
>languages, such as FORTRAN. Formerly, it was OK to use a very convoluted
>flow based on GOTO -- lots of jumping around, giving us "spaghetti code."
>The Dykstra came along and preached the gospel of "structured programming
>(more like the above). A lot of programmers fought the idea of a "right"
>way to do flow.
>Having listened to more than a couple CS teachers describe their curricul
>I'm seeing the procedural-first, OO-next approach is fairly widespread.
>good thing about Python though is the OO model is deeply engrained, and j
>to begin explaining dot-notation is to enter the class/object discussion.
What I come to is it's easier to think of objects as something you use, as
>primitives in the language, within procedural flows. Then take what you'
>learned about writing functions to write methods and start rolling your o
>classes. At that point, the full power of the OO model will start to daw
>What you say about getting into exceptions early is food for thought. I
>think you're probably right. Error handling is where the procedural flow
>gets especially ugly, what with all those case-based validations (switch
>statements trying to pin down all the ways a piece of data might be wrong
>However, once again I think students may gain a deeper appreciation for
>exception handling once they've been exposed to the old way of doing it.
>But that doesn't mean weeks and months of coding in an "obsolete" style.
>One could go through the history in a short lecture, with projected
>> There isn't a lot of use in teaching people the procedural necessity of
>> doing a huge amount of data validation, and how to deal with the 'canno
>> happen' of malformed data. It makes for really ugly code -- where it i
>> close to impossible to find out what the code is supposed to do when
>> nothing is wrong, and everything is working properly, because over 80%
>> it is to detect problems you hope you will never see
>> just my 2 cents,
>Yes, you've got a point. Validation still consumes lines of code, and we
>still prompt the user to try again, but the code isn't so gnarly.
More information about the Edu-sig