We're about to embark on helping with a new-to-coding boot camp at my work, where people from other departments can come learn how to code from the IT folks. While this is great and all, I'm in a pickle. I've been requested to come up with a way to physically demonstrate the concepts of inheritence, polymorphism, has-a and is-a relationships with a physical demo of some kind. Effectively, they're asking me to use props to demonstrate these concepts to folks who know nothing about programming and computer science!

Are there any good analogies or demonstrations you've used or seen to demonstrate these principles?

closed as too broad by gnat, Doc Brown, amon, Andres F., Bart van Ingen Schenau Nov 27 '16 at 11:12

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I guess that Google will return lots of examples. – Thomas Kilian Nov 23 '16 at 22:20
  • 2
    Hi Adam, don't get me wrong, but this is a typical kind of question which is either too broad for this site, or needs references to third-party resources, which is also off-topic. It also falls under the "educational advice is off-topic" category. I recommend self-deletion before you get tons of downvotes from the community. – Doc Brown Nov 24 '16 at 6:50
  • 3
    Beware that you don't mix up "is-a" in the sense of "is-an-instance-of" and "is-a" in the sense of "inherits-from". Classes are concepts of things, but the objects around you in the training room will be instances of classes. – Simon B Nov 24 '16 at 10:02
  • 1
    Please don't let your other departments start writing code for the business. – gardenhead Nov 24 '16 at 17:50
  • 1
    By the way, I just nnoticed than no one has explained what is an INTERFACE. To be honest, I think it would be better to drop the inheritance, and just talk about interface. Since interface can directly be mapped to fonctionnalities, this is easier. – Walfrat Nov 25 '16 at 8:30
up vote 12 down vote accepted

Teaching OO principles to non-programmers is like teaching scuba diving to people who can't swim.

That said, here's some posibilities with suggested props you can take to the classroom and pass around (or at least show) to illustrate the concepts:


Inheritance:

Props:

  • A series of iPhones of different versions, since the first iPhone, through iPhone 6, 6+ etc.

Explanation: tell them than each new iPhone is an incremental improvement of its inmediate predecessor. That most of the innards are the same, but some have been improve upon. The same for functionalities. Tell then even that some parts could ve literally the same parts of the very first iPhone that had no reason to change.

enter image description here


Polyporphism:

Props:

  • A series of electric household appliances, like a coffe-maker, a TV set, a blender, a radio, a desk lamp. Also a wall socket.

Explanation: As all the appliances comply with the same interface (all of them have plugs with prongs fitting the wall socket holes), all artifacts cat get power from such a plug. From the point of view of the socket, it doesn't matter what type of appliance you are plugin into the mains as long as it complies with the socket "interface".

enter image description here enter image description here enter image description here


Is-a:

Props: the aforementioned iPhones

Explanation: every iPhone 7 is an iPhone, every iPhone is a smartphone, every smartphone is a phone.


Has-a: Composition

Props: the aforementioned iPhones, plus a detached touch-screen panel.

Explanation: every iPhone has a touch screen panel (the transparent thing with a flat cable attached to the side). The touch screen panel separated from the iPhone is of not of much use. You don't see people carrying in their pockets detached touch screen panels with the flat cable hanging out.

enter image description here

Has-a: Aggregation

Props: A keychain with keys, laser pointer, a cap opener, a flashdrive, a car alarm control and other trinkets and fobs.

Explanation: A keychain is a composite object with a lot of keys attached to it, the keys, laser pointers and can openers can work by themselves without being attached to a keychain and neither the keychain or the tool (key, etc) is left in an unstable state. You can add and remove this items to the keychain but they can exist by themselves as functional tools. The keychain itself can be epmty, and you can't say it is broken because of that.

enter image description here


NOTE: those classes won't really teach people OOP, same as Chineasy method won't teach you mandarin. It will just be a fun (hopefully) insight to an alien way of thinking.

  • 1
    For inheritance I like another smartphone analogy: pure Android phones vs Android phones with manufacturer stuff on top. The latter clearly inherit from the first. Your series of smartphones is more like different releases of a product, less like inheritance. – RemcoGerlich Nov 24 '16 at 13:27
  • @RemcoGerlich OP asked for physical examples. You are talking about software (Android OS). Besides, an LG phone and a HTC phone are unrelated, different implementations of something, what biologists call convergent evolution. They just use some flavor of the same OS (again, software). The iPhone example is about physical things built incrementally over the blueprint of the previous generation instead of inventing it all from scratch everytime. – Tulains Córdova Nov 24 '16 at 13:48
  • 1
    This is awesome. I have to remember this post next time I have to explain that :) – Quentin Nov 24 '16 at 19:03

Start with the basics. Don't use physical objects as props to suggest things that might be objects, because that's a misleading way of thinking about object-oriented systems. Instead, take a leaf out of the Royal Institution Christmas Lectures and use your audience as props. Get several of them to volunteer, and assign some of them the roles of being objects in an actual, realistic object-oriented system. Maybe have one of them be a queue and a few others producers and consumers, or something like that. Show them that the important thing about an object is its behaviour in how it relates to other objects, not what it models (because in many cases it doesn't really model anything tangible).

  • Good idea and it looks a lot like Xtreme Programming CRC cards "game". – Tulains Córdova Nov 24 '16 at 21:20

My personal experience is even some junior developers without any academic background in computer science who have just learned programming by searching on the internet can not properly comprehend the details of OOP. For example using proper names for properties or writing short methods, and the list goes on. I think teaching OOP concepts to people who have never been exposed to programming is an overkill and would quickly turn into disappointment.

I would suggest start with some basic of programming in the language of your choice and then slowly ease into why you are for example inheriting from another class or why you are creating nested classes and then finally tell them "Ok, this thing is Is-A relationship and that thing is Has-A relationship", etc.

You should focus on the most important features of OO. These are encapsulation, interface/implementation distinction and loose coupling.

What you should not do is make a big deal out of inheritance hierarchies and use taxonomies as a metaphor for this. First, inheritance is not that important a concept in OO, second, the popular metaphors are actually more misleading than enlightening. Classes are actually nothing like species of animals or fruits or whatever.

I think a kitchen would be a useful metaphor. A kitchens requires a lot of complex functionality in order to be able to cook food. But it is not built as one big interconnected machine. Rather it is built of components like oven, fridge, sink etc. Each component have a single well-defined purpose. They are replaceable - you can change the oven to a different oven from a different vendor, and it will even fit in the same space and have basically the same interface. They all connect to the same pipes and outlets. The components are loosely coupled: Changing the oven will not cause the fridge to change its behavior. A design fault in the fridge will not affect the other components. The oven-repair man only need to be expert in ovens.

Now consider if a kitchen was built as one big "machine" with all this functionality (ability to bake, freeze, stir, cool etc.), but not separated into components. You would not be able to replace or add components from different vendors. Possibly some of the functionality in this particular kitchen is sub-par, but there is nothing you can do. The repair man will have to understand everything because it is one big machine. There is high risk that a design error in the oven will cause the sink to explode. And so on.


Note that this will not help anybody to learn to code though. You don't learn to code through metaphors - you learn to code by writing code to solve problems.

  • +1 For pointing out that animal analogies are bad examples. – Tulains Córdova Nov 24 '16 at 21:18

Use Animal Classification, and stuffed animals if you like

This strikes the right balance of fuzzy approachability with a feeling that this is serious “science stuff.” Use some cheap stuffed animals as props, if you like, and maybe use a PowerPoint presentation with frequent animal photos — people like animals, and most will “perk up” whenever they a good animal picture.

It helps that the biological classification system is a “real thing” and that most high school graduates will remember it a little.

CAVEATS:

  1. The one caveat is occasionally you can run into a person whose world view is challenged by discussing a subject related to evolution. You can assure those individuals that you are “just talking about animals classification.”

  2. The animal metaphor works best if you know a bit about Biology and the animal classification system. If you really don’t remember your High School bio, and forget the common attributes of mammals, you might be better off using an example you can speak authoritatively about.

    In any case, avoid high-tech themes for your example. Most lay persons really don’t care about computer models or peripherals. These motifs will just reinforce notions your audience will probably already have, walking in, that this whole subject is “for techies only.”

Concepts to describe:

Classes and objects — The ideal of dog, vs individuals dogs.

Method and attributes — Dogs are furry. Dogs can bark.

Overrides — Not all dogs have hair.

Inheritence — Dogs are mammals. Dogs can generally do what mammals can do (method inheritance) have attributes that mammals have (attribute inheritance).

Abstract Classes — No actual animal is just a mammal.

Inheritence from a concrete class — Scottish deerhounds are dogs that have no bark method.

Composition — A dog or another animal can have a collar, but a collar isn’t part of the animal.

Slightly more advanced concepts

The above is as far as I’ve ever taken it with a first talk, but you can go on:

Association — A dog or a cat can have a collar. But the collar is also an independent object. You can give the dog away, but keep the collar.

Aggregation — A fish may belong to a school. If the school is swallowed by a whale, the school is destroyed, along with all the fish in it.

Inheritance Chains — Dog is a Mammal is a Vertibrate is an Animal is a life form. (And point out that computer systems can be this complex too.)

Involve your audience

These are all tough concepts, and you are probably going to get a lot of glassy stares if you don’t actively keep folks involved and talking.

For example, don’t list dog attributes and methods yourself, ask for input from the group. (People are hard-wired to be interested in animals, so that helps.)

  • Note sure about composition, I would better to for something like a computer is composed of CPU, .... By the way you forgot to distinguish strong (composition) and weak aggregation. If I die, my hand will die too, but not my computer. Override : more something in the line : not dog attacks the same way. – Walfrat Nov 24 '16 at 16:04
  • 1
    Animal examples to explain OO concepts is not one of the best choices. Too leaky and juvenile. Also, OP wants to use physical props as didactic resources. – Tulains Córdova Nov 24 '16 at 17:03
  • 1
    @TulainsCórdova, your own answer hints at how unsuccessful you have been at teaching non-technical people the basics of OO. Animals keep people more engaged, and there's nothing "leaky" or juvenile about Biology. Also, my answer mentions props in the title. – Tim Grant Nov 24 '16 at 17:50
  • @TimGrant I've never taught or explained OOP to non-programmers, but I've seen others fail using animal examples. The science branch of biology is not leaky or juvenile, I was talking about explaining OOP with animal examples. It's so trite. No offence intended. – Tulains Córdova Nov 24 '16 at 17:54
  • @TulainsCórdova, you say leaky, juvenile, and now, “trite”? Triteness would require the audience to have heard it before, and this audience has not. Do you have any actual insights to offer, or are you just throwing shade on a competing answer? – Tim Grant Nov 26 '16 at 13:02

LEGO

Get some lego and build a car (base class)

Then have the same car with lights (added functionality)

Then the same car with big wheels (overrides)

Then get a motor bike (different base class)

Then get a car with the tyres taken off two wheels and one light. make it look awful. (trying to lever the motor bike functionality into an existing system)

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