Teaching Classes and Objects

I taught it using this approach:

• Start with a open ended question that gets them into thinking: "Are you a human? Why? Am I a human? Why?"
• You start discussing the differences and the commonalities that all humans share. Steer the direction if necessary, you should reach the conclusion that all humans have a nose, skin color, eye color etc. but for every human being the "values" for those "attributes" can be different. Start making a list of people in the room that is a simple list like: Ted: eyecolor=green, haircolor=brown, ...
• You establish the concepts human and human being. Every human being is a human filled with values. A human cannot come to live without the values to all its attributes being known. (This probably needs further thought)
• You introduce class by saying that human is a class for human beings
• Test his understanding by giving him two instances of things in the room that belong to the same class. Maybe two pens, ideally you have a red and a blue one. Let him transfer the class concept onto them. Then present him another blue pen that is visibly different from the first blue pen (make or something). Let him refine his pen class.
• I found it worked better when you didn't introduce object until very late and always talked of classes come to life or instances of classes
• From there you can start exploring other things like identity and equality between two humans, how do you create new instances (maybe when he's older ;-)), inheritance ...

The analogy worked pretty well for me, just make sure to not push it too far and don't force the lecture onto him.

I used post-it sticky notes.

Class is a piece of paper on the desk with a stack of post-its.

Each instance is a post-it with state written down on it.

Post-its do stuff.

The class (the piece of paper on the desk) never does anything except create more post-its.

I've also uses Koosh balls to illustrate message-passing and collaboration. The balls are requests that get passed around. Actually, it's processor state, but folks don't need to know that.

A GUI form designer is a good visual representation. A common chunk of code allows the creation of the same type of object (like a text box) to be instantiated multiple times. Create a custom form element of your own to show how it works.

I've had luck with a playing card analogy. An object is an instance of a class as the 2 of clubs is an instance of a playing card. You'd write the Card class once and create 52 separate instances of a Card in order to create a Deck. That provides some natural segues into how you would represent the Cards in the Deck class, how you might have different Deck objects, one with the standard 52 card deck but others with the jokers still in the deck, etc.

You may try the example of a paper form. The original paper form in its blank state represents the class.

When a copy of the blank form is filled with data about Jim, the data represents the object for Jim and when another copy of the blank form is filled with data about Suzan, then the data on that form represents the object for Suzan.

The data items could then represent the properties of the class.

This is clearly a simplification (accurate or not!) that may bring the picture closer to the learner.

Maybe try with the old "What do you want to be when you grow up?" question. What he wants to be is a class, and he'll be an instance of it. You can even extend it by discussing things like doctors or other occupations that have specialists. A doctor is a class, and a surgeon is a subclass of that class. All surgeons are doctors, but not all doctors are surgeons. A surgeon should be able to stand in whenever a doctor is needed, but if you need surgery you don't go to just any doctor, you go to a surgeon.

I'm trying to teach how an object is just an instance of a class to a buddy of mine.

IMHO your trouble to teach that to you buddy is, that actually it's incorrect.
No doubt, there are programming languages, where objects can be constructed by instantiating classes. At the same time, in most programming languages that have class objects, class objects are not commonly constructed by instantiation.

The point is: explaining objects using classes is like explaining cars using car factories. Much like the latter is a poor choice to teach driving, the former is a poor choice to teach OOP.

For the sake of using a rather widely spread language, let's illustrate this in JavaScript:

var dog = {
    pat: function () { print('woof!'); }
}
var cat = {
    pat: function () { print('meow!'); }
}
var peter = {
    goodMood: false,
    cheerUp: function () { this.goodMood = true; }
    pat: function () {
        if (this.goodMood) print('thank you!');
        else print('put your hands off of me!');
    }
}
dog.pat();
cat.pat();
peter.pat();
peter.cheerUp();
peter.pat();

See, we have three distinct objects, without using classes. But we already see the most important things: polymorphism and encapsulation of state.

All this is nice, but what will you do, when you need more that one dog? Wouldn't it be nice to have means to not create every one of them by hand? And still, without actually resorting to classes or prototypes, we can solve this:

var dogBreeder = {
   getDog: function (name) {
      return {
         name: name,
         pat: function () { print('woof!'); },
         call: function (name) { 
            if (this.name == name) print('woofwoof!');
            else print('rawr!');
         }
      }
   }
}
var steve = dogBreeder.getDog('Steve');
var alan = dogBreeder.getDog('Alan');

While undoubtedly, with most JavaScript implementations the approach above comes down to throwing memory out the window, it introduces the concept of a factory without depending on another addition (such as classes or prototypes). It practically shows the distinction between an entity who's purpose is to provide other entities and the entities it provides.

And now is a good time to talk of classes and the advantages they bring.

I like the cookie cutter metaphor best, you can back it up and ask things like - what makes a cookie a cookie (and not a cracker) and even further to other baked products like a soft taco shell. So that the recipe maps to the class somewhat.

I find it much easier with new programmers to just point out that for now, there is no difference between the class and the object. For all intents and purposes, they may as well think of the class as being the object until such time as they actually understand what's going on.

I'm a strong believer of learning by doing and sometimes in computer programming there can be a lot of information skipped over just to get to the point of accomplishing something and then explain why later. It would be nice if everyone could retain and understand theory before practice but it simply isn't the case.

I used the very simple Person class below to teach my ten year old about programming, and didn't bother explaining what objects were at all, I just used them:

class Person { String Name; Long Age; };

Dude = new Person();
Dude.Age = 14;
Dude.Name = "Dude";

Then we moved on to adding a getBirthyear() method and an isOlderThan() method and eventually you end up with this functional piece of code that lets you compare Persons to each other in an obvious way without ever having discussed that "Dude is an instance of class Person."