Demonstrate Object Oriented Principles to non-programmers using physical props [closed]

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/336717

Question

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?

Was it helpful?

Solution

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 improved upon. The same for functionalities. Tell then even that some parts could be 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.

OTHER TIPS

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

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.

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

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)

Licensed under: CC-BY-SA with attribution
scroll top