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
- Anonymous
April 07, 2006
The comment has been removed - Anonymous
April 07, 2006
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.
-Jerod - Anonymous
April 07, 2006
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. - Anonymous
April 07, 2006
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." - Anonymous
April 07, 2006
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? :)) - Anonymous
April 07, 2006
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. :-( - Anonymous
April 07, 2006
The comment has been removed - Anonymous
April 07, 2006
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... - Anonymous
April 07, 2006
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 (25x20! 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. - Anonymous
April 07, 2006
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? - Anonymous
April 08, 2006
The comment has been removed - Anonymous
April 08, 2006
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). - Anonymous
April 08, 2006
John Montgomery is really asking the good questions these days. One of the things that teachers struggle... - Anonymous
April 08, 2006
To explain this to an 8 year old you would need to do some drawing.
Eg:
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 ... - Anonymous
April 08, 2006
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. - Anonymous
April 09, 2006
Our next version of Visual Studio (the next version of the product is known internally as 'Orcas') is... - Anonymous
April 09, 2006
The comment has been removed - Anonymous
April 10, 2006
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. - Anonymous
April 10, 2006
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. - Anonymous
April 10, 2006
Neat, Nick. I think that might work. - Anonymous
April 10, 2006
Mr. Potatohead? - Anonymous
April 28, 2006
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.