Explain Inheritance to an Eight-Year-Old

One of the charters of my team is to try to make the process of learning to program more fun. There are a lot of things we can, should, and will do here. One thing that has stood out for me is how many people have told me they don't understand object orientation at all, and they don't mean that they don't grasp polymorphism. They mean the concept of a class is alien to them.

As a thought exercise, I've run several of my coworkers through some of the "breakthroughs" I think that a beginner makes as they learn to program. One of them is the  understanding of basic "cause-and-effect" programming (e.g. if I change the backgroundcolor property, the background color changes). Another is understanding variables. Another is understanding loops and conditionals.

All of these are easy to explain because they have analoges in the physical world. Inheritance doesn't seem to work like that. How do you explain that there's a kind of master entity and that other entities all derive characteristics from it, that you can change these characteristics yet still maintain the relationship between your changed entity and the master? The idea of parents and children doesn't apply (that'd be closer to polymorphism). Amoebic division doesn't apply.

What's a real-world analog to inheritance that I could use to explain it to an eight-year-old?

Comments (22)
  1. Tim says:

    The animal kingdom? With all the classifications?

    That’s the first thing that pops into my mind

    Perhaps silverware? Knife: Butter Knife, Steak Knife. Fork: Sald Fork, Regular Fork, Dessert Fork… i’m not sure if the characteristics of those change enough to give them an idea.

  2. Jerod Bennett says:

    An odd analogy could be the PlayStation 1 -> PlayStation 2.  The PS2 can do everything the PS1 can, and then it has new abilities.  Additionally, some of the old abilities have been enhanced.


  3. Jason says:

    Why not the classical animal analogy? Where you have numerous animals which are specialized into sub-classes such as reptiles and mammals. Each sub type has it’s own characteristics. Most 8 year olds understand that generally reptiles have scales, and mammals have hair. These classes can be further specialized into differing species, like canines, felines, etc.

  4. Me: "When grandma died…we got her stuff…that is inheritance."

    Kid: "So if you die I get your stuff?"

    Me: "Yes. But you’d most likely inherit my bills too."

  5. Mladen says:

    maybe evolution?

    we all started from a cell then we evolved

    like inherited classes evole but they still maintain the same properties as the original cell (inner cell workings). there’s just many of them…

    and that goes on and on…

    will that do? :))

  6. johnmont says:

    This is a hard problem. All of these kind of work, but have a place where they break down. Evolution doesn’t work because a) if you change the "parent" the "children" don’t change and b) it occurs over time. (Plus, if you believe some people, evolution is a myth.) Animals don’t work for similar reasons. Even the PS1-PS2 analogy doesn’t work because it’s a versioning that happens over time and if you change the PS1, the PS2 doesn’t also change.

    No answers, only vetoes. 🙁

  7. MSDN Archive says:

    Transparencies, perhaps?  Though this may be a better way to explain interfaces.

    You take a plastic sheet, draw a box on it, with a little bump to represent some characteristic.  Take another, and overlay it, drawing another bump.  Add another overlay a repeat.

    Remove the overlays, and repeat — this is a different branch in the hierarchy.

    Methods are looking for a particular set of bumps, and inheritance is a way to progressively add bumps.

  8. Mladen says:

    Well i didn’t mean evolution as parent child thing…

    i meant it at a cellular level.

    i’m a complete app.

    my base class is a stem cell that specializes by sub-classing. so we get different kind of tissues (child classes). that is cellular evolution.

    you change the stem cell you change the whole me.

    each person is a machine running an exe with additional DLL’s. if you change the base class and recompile on one machine (person) that machine’s (person’s) properties change.

    modern day genetics. :))

    somehow it think this applies…

  9. MSDN Archive says:

    Transparencies are pretty good, that may end up being the best match.

    While I think it likely bleeds too much into other concepts, I want to go with a "blueprint" approach.  Specifically, I think there’s some importance to relating type definitions as blueprints for a house, where actual instances of the types represent fully-constructed (semi-pun intended) houses.

    In such a scenario, one could define a "base blueprint" that’s, for instance, a single story home with a 500 sqft kitchen (25×20! rock!), 500 sqft living room, 500 sqft home office, and 100 sqft foot bathroom for a total of 1600 square feet.  This base blueprint is pretty useful for some things (for instance, it has all I would need for most "work at home" functions, but not useful for others (it can’t host a 100k person concert).

    On to this base blueprint, we can add additional blueprints.  These don’t change the base blueprint, but they make the resulting structure more useful for a particular scenario.  For instance, this "subclass" blueprint could add a second floor with 4 bedrooms and 2 baths.  Even further, a third blueprint could extend this second one to add on a 2-car garage (etc. etc.)

    Then, you can change the "parent"/"core" blueprint (say, to make the kitchen a little smaller and add a laundry room downstairs), and you end up changing the "subclass" blueprints since they’re based on it.

    Unfortunately, there are lots of problems with this approach:

    – blueprints are a bit abstract already, so this approach may do more harm than good given the target audience

    – overly tied to the type vs. instance separation – if you change the "core" blueprint, it does automatically change the "subclass" blueprints, but it doesn’t change houses that were built with the blueprints before they changed.

    – similarly, we rarely (but not never 🙂 deal with types changing over the course of a program running, so it’s generally odd to think that you’d have 3 instances that came from 3 different versions of the same type (at the same time), but that’s perfectly fine with blueprints and houses.

    Transparencies are likely better – I’d imagine there’s a better chance that an 8-year-old has some experience with them rather than blueprints, too.

  10. johnmont says:

    I like transparencies a lot — a lot a lot, actually. I wish I’d thought of it.

    So what other concepts needs to be explained to an eight-year-old?

  11. Andrew Wilkinson says:

    I’ve always thought of food, and in particular fruit as a good analogy for object-orientated concepts. For example – Orange derives from CitrusFruit derives from Fruit derives from Food. Then you could add properties at sensible points – Colour (sorry "Color" for the US!), HasPips, etc. And finally methods – Eat(), Peel() and so on.

    Advantages: food is something everyone understands. Plenty of room for people to think of their own ideas. It is obvious that an orange is a citrus fruit, which is a fruit, etc. And for polymorphism you can envisage being able to use a ‘Fruit’ without knowing what type it is (in fact think of being given an unknown fruit – you could still see its color, if it has pips, eat it etc. without knowing what it is called).

    Disadvantages: Why would you ever write a class library of fruit?!?! Also the fact that most of the things (Food, Fruit and CitrusFruit) would likely be marked as ‘abstract’ to confuse things

  12. Much easier. thats to complicated.

    since i think an 8 year old boy is playing some rpg’s like world of warcraft i would start with that.

    you get an "start character" where you can choose from. the base. and its up to you, want you want to change and do with it. but its allways derrived from your start character. with all its characteristics.

    or you get give him some modeling clay and say, thats your base. do something with it…. thats intertiance (maybe if you find a boy, that didnt played with rpg’s).

  13. John Montgomery is really asking the good questions these days. One of the things that teachers struggle…

  14. To explain this to an 8 year old you would need to do some drawing.


    Draw a simple house then draw a second drawing where you start from the same house but add a garage…

    Draw a simple car then draw a second drawing where you start from that simple car but add some extra’s. Create a third drawing starting from the second drawing and add some extra’s …

  15. Mike Sanlon says:

    I’d use a cookie recipe and a basic magic gag. Write a recipe for a plain cookie on the chalkboard. In one hand, have a plain cookie, in the other, palm a small chocolate chip one. Add chocolate chips to the recipe on the chalkboard and then show the class the chocolate chip one. Tell them that the magic of "inheritance" is that not only do newly made cookies contains the chips, but every cookie you ever made with the recipe now contains chips.

  16. Our next version of Visual Studio (the next version of the product is known internally as ‘Orcas’) is…

  17. johnmont says:

    All these food suggestions are making me hungry. 😉

    But do you really think that kids get that limes, lemons, and oranges are all subclassed from some non-existent thing called a citrus fruit?

  18. Jeff Parker says:

    I like Christoph Richter’s and Gabriel Lozano-Morán’s explanations the best sometimes it is easier to visualise things in a computer with real life things. Especially to an 8 year old or anyone really. Take programming and the computer completely out of it and give them a real life example.

    One that I thought of before reading the responses and have used before is take a cup. Any plain old cup. Then by inheriting the cup you are not recreating the cup but adding on to it like say you want a logo on the cup. That is a simple enhancment of a property to the cup. The base cup or the original cup may have just been a cup used for water so it had a method called refill in which would go and refill the cup with water. However this new cup is a coffee cup. So you can override the refill method and instead of refilling it with water you refill it with coffee. Using this thinking you can set up other areas and give other example. Anyway I always find taking the computer completely out of the explanation and giving people something they use every day as an example helps them visualize it.  

  19. Nick says:

    I have to explain these concepts to ex-mainfame programmers a lot.  I use the "blueprint" concept for inheritance, and find it to be incredibly useful.  The other thing it helps to explain is when you need to create a variable of a certain type, and when you instantiate a specific instance of that type (what a lot of the mainframers here call "the new problem").

    The blueprint analogy works perfectly here.  The blueprint represents the variable, while "newing" it is building the physical house from the blueprint.

    I’ve even talked about handing the blueprint to a home inspector who needs to get to every kitchen in the neighborhood.  If your blueprint is for "SingleStoryHouse", and someone in the neighborhood inherits and builds a "TwoStoryHouse" that shares the "SingleStoryHouse" blueprint, the home inspector can still get to the kitchen without ever knowing about the second story in some of the homes in the neighborhood.

    For interfaces, I find the remote control analogy works best.  I describe a VCR, DVD player, and DVR that all implement IPlayback.  Even though each of the playback devices use different physical implementations (magnetic tape, optical disk, hard disk), the same remote control can run them.

  20. johnmont says:

    Neat, Nick. I think that might work.

  21. petal says:

    Mr. Potatohead?

  22. Michelle Hutton says:

    I think many of my (middle school) students would have a hard time with the idea of the blueprint – it isn’t something they’ve experienced before.

    To explain classes and inheritance to them, I use themselves. (Middle schoolers are notoriously self-centered, so it works particularly well.) We talk about the properties of the class "student" – all students have certain rules (methods) such as that they must wear a uniform. We can change the rule for the class (such as adding or removing a piece of uniform wear) which changes it for everyone. Each individual has other attributes that are unique to the object, such as height and hair color.

Comments are closed.

Skip to main content