[Edu-sig] Explaining Classes and Objects

[Kirby Urner]

> 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 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).
> 
> 
> 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 start
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, as
in Python we have top-level functions, and procedural programming is mainly
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 curricula,
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 just
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 own
classes.  At that point, the full power of the OO model will start to dawn.

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 'cannot 
> happen' of malformed data.  It makes for really ugly code -- where it is 
> 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