[OT] about OO concepts

[Michael]

> Well, last time I tried to explain OOP I started with the 'object' 
> concept (object = id + state + behavior), then came to the 'class' 
> concept, first defined as 'a class is the set of objects that share 
> the same behavior'. It's hard to tell because no two brains works the 
> same, but it seemed that the person I was trying to teach OO found 
> this approach quite clear...

I always teach the object concept by putting objects into real world 
terms. An object is a car, cup, or bowling ball. Each has properties 
that help define what the object is. Color, weight, or size. Each also 
has methods which are things which the object can do. Start it's engine, 
be sipped from, or be rolled. Even novice programmers can pick that 
concept up pretty easily. Classes take a little more work. Just 
explaining that there could be different types of cars which in turn are 
different types of vehicles but that certain design aspects are often 
the same. I just explain a class as being a design for an object and 
that when you instantate an objectit's like manufacturing something from 
a design. Most people grasp the idea pretty quickly when put into such 
non-abstract terms. I might explain polymorphism as something like 
different brands of the same item. Your car can use generic tires that 
cost $50 or stylishh tires that cost $500. As long as they follow 
certain design rules they are interchangable parts but they can differ 
greatly  outside those rules.

Maybe it's underestimating people but I think a lot of novices don't 
really understand the abstract ideas we throw at them. I see even 
somewhat experienced coders still avoiding using such things as 
functions and objects. Clearly not good. :)