What is a good analogy for the Object Oriented paradigm?

Question

What is the most effective analogy that you have used or have thought of to teach the object oriented paradigm? Hopefully the analogy can translate well to inheritance as well, and includes the concepts of instance methods, class methods and properties. Even better would be if it also includes the concept of singleton classes.

A similar question exists on Stack Overflow. I would like to duplicate it here because on Stack Overflow it was closed an "Not Constructive."

It also exists on Software Engineering, where is not closed but it has historical lock. This means that "it is not considered a good, on-topic question for this site." Again, it should be re-asked here.

Answer 1

I've got to jump in here and talk about my experience having to help a former boss understand why the project he wanted to do wasn't possible in the time available. It came down to incompatible data types and he just couldn't see why I couldn't convert from one to the other (he wanted to do real-time motion capture using an XBox Kinect to animate a 3D mesh of the circulatory system and thought this was easy).

Ben I.'s answer touches on this too, but I can add to it. He says this:

The objects keeps track of some kind of information (instance variables), can be interacted with only in specified ways (interface), have setters (switch/button) and a getters (lights, your eyes).

There's more to it than that. In this electrical engineering paradigm (which should be familiar to most), a light switch that has two states is the most basic example.

• It has output: bool isOn()
• It has a method of supplying input: toggle()
• Underneath it has an implementation of what toggle() does and how that affects the return value of isOn()

Buttons can also be described in this manner:

• It has output: bool isOn()
• It has a method of supplying input: push()
• Underneath it has an implementation which differs from Switch slightly: after push() is called the output is true for a short duration, then automatically returns to false. That is, the user must continue to interact with the button in order for the output to be true.

A knob also has similar features, although different types are involved:

• It has output: float getValue()
• It has input: twistTo(float v)
• Underneath it has an implementation

But here's where it gets interesting:

What happens if we define an object that implements both Knob and Button? We should expect the following description:

• It has output: float getValue(),bool isOn()
• It has input: twistTo(float v)
• Underneath it has an implementation
• After input is supplied, isOn() becomes true, then after a duration becomes false again. In order to keep isOn() returning true forever, we must continue interacting with the object.

What do we end up with?

We can twist it to set the value, which turns the output on and displays the value. Then after a duration defined by that value it turns itself off again. As the homeowner we don't care how it was implemented only that they can interact with it in a certain way (defined by those interfaces) to get the desired behavior.

And yes, I'd present that to students in that manner. Describe the simple items (button, toggle, knob, timer) and then ask the students to figure out what happens when two of them are combined. The epiphany moment when it clicks will do wonders. That's the difference between being told and being taught.

You can expand on this analogy quite far, as well: Three-way switches, time-locks, missile launch confirmation (you need to press two buttons at the same time), sliders, gauges...

And then...you can get to events. Instead of treating the wires in the analogy as hard links in code (while(switch.isOn()) { ... }), you can treat them as events: when the switch changes state, that update propagates to all objects listening for it and they handle the state change as their implementation dictates (switch.addListener(this.doWhenToggled)).

The classic "cats are felines, felines are mammals, mammals are animals" hierarchy only gets you so far and provides a very poor and rigid understanding of Object Oriented Programming that causes new programmers to tend towards Do-Everything Objects (where do float planes fit in the "boat extend vehicle, plane extends vehicle" hierarchy? Clearly the only solution is to make all vehicles drive, fly, and float and just disable the ones we don't need!) rather than through a composition of interfaces (say, FloatPlane extends BaseAircraft implements IWaterCraft).

I know that sort of thinking messed me up for a number of years. Heck, I'm still recovering from it: I still can't read inline lambda expressions natively, I have to decompose them, and it often takes me several minutes. Same thing goes for creating interfaces, I often have to go the "cats are felines" road until I hit a spot where I realize "I want to use this code on both cats AND cars" because they both share some property that doesn't exist in the common class (and shouldn't) and I have to refactor.

Of course, refactoring is a good thing. Give your students a powerful IDE and teach them how to use the refactoring tools. Eclipse is the god of these , offering an astounding fourteen different options, including "Extract Interface" and "Use base type where possible." Even if they make a mistake, now they know how to fix it in moments rather than hours. No one wants to (and no one will) spend hours fixing an inheritance problem that can be solved by a quick copy and paste; "code duplication, meh, never hurt me."

Answer 2

A good analogy might use animals and their classification.

Class: think felines. A feline will purr, go out only at night, eat meat, etc. One could think of the methods purr, goOut:time, eat:food, where a valid feline will only accept a night time and food that is meat.

Inheritance: meanwhile, felines are very different from each other, despite sharing much of the same physiology (implementation). They observe many similar behavior (interface), but different types of cats have different behavior ultimately. A domestic cat's purr will be very different from a tiger's. Meanwhile, a tiger will be able to predate on another animal (think the method predate:), but a cat will not.

Instance: specific cats. My neighbor's kitten, the tiger in the city zoo, a lion somewhere in Africa, etc.

Answer 3

I mean, one very clear analogy for Objects is, well, objects. But these are special sorts of objects. You might show some videos like this one to make it clear:

• https://www.youtube.com/watch?v=XCEtl9CfbAU
• https://www.youtube.com/watch?v=exGtj4jjbco

The objects keeps track of some kind of information (instance variables), can be interacted with only in specified ways (interface), have setters (switch/button) and a getters (lights, your eyes).

So, we are talking about objects that have the ability to do things, have interfaces by which you can get them to do them, and don't show you how they work inside.

Then you have a nice segue into constructing an Object together.

What nice about using objects as an analogy for Objects is that, well, that's what they were named after, so that's really the philosophical conception from the start.

Answer 4

I have thought of different sizes, shapes and colors of boxes.

This would work better for younger students, and would work better if you use the box analogy for variables.

Basically, all boxes are boxes. Some are square and some are round. There are white square boxes and brown square boxes, but they are both square boxes and can both fit similar things. Another example: A filing cabinet or cupboard is basically a box that can hold other boxes (a collection). You can of course use other examples too.

Requested examples:

Inheritance: A regular box and a cooler can hold the same types of items and are about the same size, but a cooler, in addition to storing things, keeps them cold.

Instances: Get two of the same type of box. Put an object (like a rubber duck) in one, and a similar one (maybe a different rubber duck) in the other. They are separate instances of the same class.

Properties: From the previous example, the duck in one is yellow and looks like a wizard, and the other one is orange and looks like a tiger.

More examples tomorrow, I'm going to bed.

Answer 5

A good analogy you can use is a human analogy. Everybody is a human, but each of them has a different characteristic. Different eye color, hair color, skin, etc...

Anybody can easily relate to this cause we are all human.

Answer 6

Wheeled vehicles
 |-human-propelled
 ||- unicycle
 ||- bicycle
 ||- tricycle
 |-animal-propelled
 ||- cart
 ||- carriage
 ||- ...
 |- motor-propelled
 ||- motorcycle
 ||- car
 ||- ...

This allows you to explore both subclassing and composition.

Answer 7

I'd turn the lesson on its head. Say, I am writing a game and I need to track what's going on. To start my game is going to feature a "good guy" running around fighting "bad guys". So I write Good guy and Bad guy classes.

Unsurprisingly, these classes contain a lot of similar code. They both move, etc. so we can take that code and break it out into a common base class...

... and just keep extending the metaphor. Bad Guy's need AI, Good Guys need control input, etc.

Answer 8

Lots of the answers here focus too much (imo) on inheritance. I find that I write better code when I think of OO as primarily supporting composition, not inheritance. In this view, a good analogy is an automobile. It is made up of many parts (objects) that interact in interesting ways to provide a functionality. You can substitute nearly any manufactured product, say a computer.

If you program this way you find that your hierarchies are very shallow and your classes are composed of many parts defined by other classes. It also minimizes the tendency to have class fields mostly primitives that are specifically manipulated by this class, instead having actions deferred to the other classes.

Thus, a gas pedal doesn't need to know anything about an engine, but both are parts of a whole. Likewise, recursively, the parts in the composition are themselves composed from simpler things. Eventually you get down to primitives (ints and strings) but hopefully not for a long time.

An added benefit of this world view is that you can, for the longest time, write the program using names associated with the problem space rather than the solution space. So a car has a GasPedal with a method press, rather than having an int that is just directly manipulated by the automobile object. I find naming according to the problem space, not the solution space also helps one communicate with users/product owners who, themselves, think in that space.

A consequence of this view, perhaps not obvious, is that the solution begins at the top level, adding classes for the parts as you find the need for them. This, as opposed to building lots of small "parts" classes speculatively hoping that they will fit. It also fits well with test first programming style.

Answer 9

I'm in the midst of a PennX course on edX called Software Development Fundamentals taught using Java, and they gave the analogy of parts of speech.

• Objects -> Nouns
• Methods -> Verbs (i.e. Actions)

I think you could expand it (without going too far with the metaphor) as follows:

• Properties -> Adjectives
• Class and (instance or subclass) -> Common noun and proper noun

This analogy is strengthened by the use of "is-a" and "has-a" in the context of OOP. The transition from natural language constructs to OOP (or vice versa) may aid in discussions of class design.

For example, a Car object could be a blue Honda Civic, the adjectives blue and Honda corresponding to properties set upon instantiation and the noun Civic either being the variable name of the instance or a subclass. Using natural language also helps with instanceof() as students will hopefully see relatively intuitively that a Civic is quite clearly a car, but a car is not necessarily a Civic.

Answer 10

One classic example (not original with me, used by many of my colleagues) comes from using modeling compounds (e.g. Play-Doh), and the many tools that come with them.

In short: you take raw memory (the Play-Doh), apply a class definition to it (one of the cutout forms), and you get an instance of an object (a Play-Doh shape). You can make multiple instances (multiple shapes) by re-using the class definition on new memory forms. Each instance can have different attributes (colors) but still belongs to the same class (collection of objects made from the same cutout).

Answer 11

A class is a small-program, an object is an instance of the small-program. A program is a collection of small-programs, that work together to achieve something bigger. A bit like Unix (bit different), where small-programs are connected with pipes. Objects are connected by messages, and you have to compile to link things together.

Answer 12

At the point in my CS1 class where we discuss OOP, my students are somewhat comfortable with the procedural paradigm. So, we first reflect on that before talking about OOP.

Procedural solutions: moving pieces of data around and manipulating them. I go back to a cooking analogy and compare programs to recipes: break eggs, add flour, beat those, add vanilla, etc. I say we think about programs in terms of basic ingredients (inputs), containers (variables), moving these around (control flow) and doing things to them (operations).

OOP: I draw heavily from Yegge's Kingdom of the Nouns to describe OOP, since I think it is both a good description and a hard criticism of OOP. The "Noun is King" and we design everything around that. Yegge has lots of good analogies directly in his description, but I don't employ all these at first. I do emphasize that we design everything around some "Big Nouns."

My primary working example of a "Big Noun" is a Whale, and I try to bring analogies back to this when possible.

• The Whale class is a category of animal, whereas bruce = Whale() and sally = Whale() are both instances of Whale. The analogy is that instances are like individuals (the human-like names are very intentional).

  I also tap into a secondary analogy: a class is like a cookie cutter and the cookies are instances. Students find the idea of "stamping out" an instance by "using the class" to be fairly intuitive. Bonus: whale cookie cutters can keep the main analogy going.

• Member functions are verbs (analogous to objects being Nouns): bruce.eat(fish) and sally.sing()

  Secondary analogy: methods are like little remora who are attached to the whale and do stuff for it, like sally.clean(). All verbs only exist if they are attached to some noun.

• Data members are data that relate to the noun. The extension of the analogy is that they are adjectives that describe the whale: bruce.weight_in_tons = 200

  Secondary analogy: these are data inside the whale, like ambergris or Pinocchio. The data go into the whale, maybe its transformed or grows while inside the whale, maybe they get spit back out later, etc.

• Inheritance: as others have suggested, the analogy is animal taxonomy. A BlueWhale is a Whale. All BlueWhale have a blowhole (like other wales) but they also have baleen, etc.

Its not a perfect analogy, but I get mileage out of it.

Answer 13

There are various analogies that work well, such as different kinds of vehicles. However I think you should quickly move towards discussing something that can actually be programmed. For example, you can discuss a system for tracking different types of employees. Game programming also fits the object-oriented paradigm well. You can first discuss the concepts of different types of game characters, and then go ahead and actually program it. (Perhaps initially students can use Greenfoot or a game maker program to create the game.)

Answer 14

I might be in minority here, but I hate using THINGS as analogy to classes. Classes are about abstracting behavior, and THINGS are not behavior.

So, in my opinion, best way to give people idea about OOP is to start with some complex behavior and show them how that behavior can be structured into classes.

Idea that immediately comes to mind is to start with some complex, procedural code and use refactoring to create class structure out of it. This will allow students to contrast and compare two possible ways how code can be structured.

Few things I would expect from this code. First I would expect there to be a complex method, with lots local variables and lots of code accessing those variables. This could then be refactored into class with local variables turned into fields and whole method split into smaller methods, each having access to the fields.

Next I would expect there to be some plain data structure, with code operating on this data structure. Maybe the above step would extract a method that works only with this data structure, and then that method could be moved into the data structure, making it a proper class. This could also work by introducing private fields, as the internals of the data structure might really be accessed by it's member method.

Next thing I would expect is some kind of switch that decided what calculation is used based on some kind of external parameter. This could be extracted first into individual class with method and then into class hierarchy with inheritance/interface, with concrete implementation passed in instead of "type" discriminator. To make it more complex, each of those calculations might want different input parameter, which might create complex method parameters, but would be simple if each concrete "calculation" class has it's own parameters.

In the end, this will show classes are just different way how to structure behavior and that there might be classes that don't have noun (or a thing) associated with them.

Answer 15

When I saw a software engineer, I always ended up using personal pronouns, when talking about classes and objects. “He does this, and tells her, then she …”. They are like people working together. And sometime they model objects.

Therefore classes are used to model subjects and objects.

We often, for hard problems, would get a team together and act out a scene to work out what the software should do. Some of the roles where played by the software developers, others by index cards, boxes, a calculator (to represent a math library), and various other props. We would act a scene several times, making improvements until it worked. We would then make notes, and then go away and implement the code.

We did not make any distinction (consciously) of subject vs object. Objects can be a bit subjecty and subjects can be a bit objecty.

Answer 16

Somewhat strangely given the name, Objects have little to do with things: they have to do with actions. Alan Kay, just about the original inventor of OO programming, somewhere defined an object as "a thing that you can ask to do things".

Since I teach programming to science-y students I use examples from math. For instance a Point object. I don't care what it contains, only that you can ask it to translate itself, compute its distance to the origin, et cetera.

What do objects have to do with data? Well, you could also take your Point program and write it using two variables for the coordinates of each point. But that would not be as clean. Also, it would make it prohibitive to change your whole program to polar coordinates. So an object is an abstraction from basic data types and defining behaviors on that abstraction.

And then you go on to make a Line object that comes from two Points, rather than four reals x1,x2,y1,y2, et cetera.

Answer 17

I asked a similar question Some real practical example to teach object-oriented concepts and programming (in python)

I highly agree with what @Buffy answered here and in my question that it is composition not inheritance that we should emphasize (or inheritance is overemphasized) when teaching Object Oriented paradigm.

To give analogy I will use the manager/worker example. I think most people are familiar with these 2 concepts and I have seen many codes name their objects just as manager/worker(sometime with jobs too). I find "What is the difference between Controllers and Services in Node REST API's?" explains the manager/worker example very well, so I just borrow his/her words

If you think about what the manager's role is, he/she typically:

1. manages the incoming work requests
2. decides which worker should do the work
3. splits up the work into sizable units ... but does not do the work himself/herself (again, using a basic stereotype here!)

And, a worker typically:

1. receives the request from the manager
2. figures out the individual details involved in completing the request
3. is generally only concerned with the tasks he/she has to complete
4. not responsible for making decisions about the "bigger" picture

The overarching theme is that the manager/controller receives the work, decides who should do it...

So manager/worker works together (composition) to do the job.

--- update ---

These 3 Q&A may be too hard for the beginner but they can be served for the follow up questions.

1. Naming Classes - How to avoid calling everything a "Manager"? The legendary "two hard things in Computer Science"

2. Can manager classes be a sign of bad architecture? Of course it depends.

3. What we should use instead of a "manager" class in a good OOP design? Short answer if a manager assumes too many responsibilities split it. Again this is also a good analogy in real life.

Answer 18

Another analogy which comes to mind is buildings.

Abstraction: You never build a building. You build a house, an apartment building or an office building.

Polymorphism and Inheritance: An apartment building is a building, but also implements the functions of Habitat. That would be an interface. So, you have

interface Habitat;
abstract class Building;

and then

class ApartmentBuilding extends Building implements Habitat{...

And this shows the basic construct (he, unintended pun) of OOP.

A singleton can be EmpireStateBuilding. There's only one, and if someone's asking for one, a reference to the existing one is given. Just before it was built, asking for an EmpireStateBuilding would create one single EmpireStateBuilding. So it's a singleton.

Now, the has-a relationship can be explained with a Wall object. Our abstract Building has a collection of Walls. A wall is not abstract, but rather concrete (pun #2), and can also be extended (pun #3?) to a InnerWall or OuterWall. The GreatWallOfChina is a singleton extending Wall.

So this analogy covers most of what's discussed when teaching OOP.