Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I'm trying to teach how an object is just an instance of a class to a buddy of mine. However, he doesn't seem to understand it so well.

I've heard a ton of the examples (blueprint to a house, etc.) But does anyone have a real concrete way of teaching this?

share|improve this question

closed as primarily opinion-based by durron597, Snowman, jwenting, Ixrec, gnat May 11 at 20:42

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

What does your buddy do? –  cspray Jan 26 '12 at 2:40
He's a twelve year old genius and the younger brother of my lifelong friend. –  psyklopz Jan 26 '12 at 2:46
Then I will change my answer to be a GI Joe action figure instead of a doll :) –  cspray Jan 26 '12 at 2:48

10 Answers 10

up vote 10 down vote accepted

I like the moulding analogy. You spend a lot of time creating the mould, fine tuning the mould and then you "pour in" various ingredients to make the specific product.

For example, think of a mould for a GI Joe action figure. You might want to have different skin tones, hair, eye color or different accessories but you don't want to have to create a brand new-from-scratch GI Joe every time. Instead you create a mould once and pour in the appropriate ingredients for your specific GI Joe needs.

Classes and objects work just like this. The class is the mould, the object is the actual GI Joe you play around with.

share|improve this answer
It's a perfectly valid explanation (and certainly age/gender appropriate), but not any different from the blueprint / house analogy, is it? –  Dathan Jan 26 '12 at 7:54
@Dathan I believe that one could argue all the valid explanations are no different from the blueprint/house. Why? Because there's really only one explanation for what a class is compared to an object. The class is a blueprint, the object is a representation of that blueprint. If the person doesn't understand that then you must restate it in a way that they do understand. Perhaps it is easier for a 12 year old to connect with making a doll, or perhaps a plaster-of-paris mould, as compared to building an entire house. –  cspray Jan 26 '12 at 11:24
@Dathan IMO mould::toy is a better analogy than blueprint::house, because unless you live in an area with a lot of tract housing a blueprint only ever makes one house. I know that confused me for a while. Everyone, on the other hand, knows that a given toy mould will make many toys (or at least will, once you explain moulding to them). Also, to most people's way of thinking, a given house is stateless; it's just a house, regardless of what happens inside. A toy has multiple states - it can be posed in multiple ways, it can lose its bits. –  Tacroy Dec 21 '12 at 19:24

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
+1 That's not only a good example or metaphor but an actually working model to start with. Writing a runnable program and playing around with it is the best way to learn after all. That example also leads easily to understanding collections and thinking about algorithms: how to sort cards, how to shuffle a deck, how to score a poker hand, etc. –  COME FROM Nov 26 '13 at 14:15

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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!');

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.

share|improve this answer

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.

share|improve this answer

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."

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.