[Edu-sig] Explaining Classes and Objects

[Laura Creighton]

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.

But 

    raise 'you are an idiot!'

in some circles has its own sort of charm ....

Laura


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
>a 
>> >of moving from the procedural paradigm to the object oriented one -- 
>> >not to traumatize, but to give the flavor of what "paradigm" even mean
>s
>> >(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
>t
>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
>s
>in Python we have top-level functions, and procedural programming is main
>ly
>just organizing the flow in terms of a main procedure branching to and
>returning from numerous subprocedures e.g.:
>
>def main(args):
>   vars = sub1(args)
>   vars = sub2(vars)
>   vars = sub3(vars)
>   return vars
>
>Procedural code starts as simply as:
>
>def f(x):
>   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:
>
>def tri(n):
>   return n*(n+1)//2
>
>def tetra(n):
>   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
>a,
>I'm seeing the procedural-first, OO-next approach is fairly widespread.  
>The
>good thing about Python though is the OO model is deeply engrained, and j
>ust
>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'
>ve
>learned about writing functions to write methods and start rolling your o
>wn
>classes.  At that point, the full power of the OO model will start to daw
>n.
>
>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
>examples.
> 
>> 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
>t 
>> happen' of malformed data.  It makes for really ugly code -- where it i
>s 
>> 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% 
>of 
>> it is to detect problems you hope you will never see
>> ...
>> 
>> just my 2 cents,
>> Laura
>
>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.
>
>Kirby
>