[Edu-sig] Explaining Classes and Objects

[Chuck Allison]

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 at python.org
DC> http://mail.python.org/mailman/listinfo/edu-sig



-- 
Best regards,
 Chuck