How to explain OOP concepts to a non technical person?

Question

I often try to avoid telling people I'm a programmer because most of the time I end up explaining to them what that really means. When I tell them I'm programming in Java they often ask general questions about the language and how it differs from x and y. I'm also not good at explaining things because 1) I don't have that much experience in the field and 2) I really hate explaining things to non-technical people.

They say that you truly understand things once you explain them to someone else, in this case how would you explain OOP terminology and concepts to a non technical person?

Answer 1

I generally try and describe Object-Orientated-Programming by using real world examples.

For example, I might say that a class called Vehicle describes the minimum things that a vehicle is. I'll ask the person to tell me what he or she thinks a vehicle is. Sometimes they say things like "Well, like a car or a truck", and I'll nod and agree with them. Then I'll ask what the differences are between a car and a truck. Sometimes they mention size, sometimes the purpose, and other things.

Then I'll ask them to forget about a car, or a truck and just ask them to continue to describe a vehicle:

"Oh, well it moves"

"It has an operator, or a driver"

etc...

Soon, we know what a Vehicle is and I said that in OOP we would define a vehicle, and for the sake of argument say it can move, and give it a driver of sorts. Then I'll ask, ok, so what does a Car have?

"Doors"

"Windows"

And then a truck....

"Doors" "windows" "More Wheels!"

Soon, after lots of discussion, the other person generally has identified:

1) What constitutes a vehicle

2) What constitutes a car

3) What constitutes a truck

4) What constitutes an aeroplane.

All without any technicalities. We've divided up the properties of each in to the right areas. They understand inheritance ("Yeah, a car is a vehicle, a truck is a vehicle, but a car is not a truck, it's SIMPLE, duh!").

They even understand polymorphism, "Sure, they basically do the same, but that might do it slightly different.". We can talk about behavior and where that should live in our tree of objects.

Depending on their education and background, some get it faster than others. But when I compare OOP to real-life objects, most people always get it. In fact, I have found in conversations with non-technical people things I had never thought of. Vehicles don't have to be manned, for example (drones), but would a programmer have thought of the operator of the vehicle as a property of it? I am not saying it is right or wrong to have an operator mentioned, but it causes us to think about what we are modelling and what we are trying to achieve when we develop software.

Now, partial template specialization, on the other hand.... :)

Answer 2

Objects are nouns, methods are verbs.

Answer 3

Here is some version of my canned answer that I give to the ultra non-technical person:

Programming is an attempt to create a representation of reality on the computer. There's a lot of tools and devices that exist that do this already -- think about how a spreadsheet makes it easier for us to represent accounting or statistics, or how a Powerpoint presentation allows us to store and display our presentations.

Sometimes we need to build custom representations of reality into new or existing applications that reflect our business processes. There's lots of ways to program, and one of the most common ways to program is object oriented programming, where the code we build is specifically designed to replicate the concepts of reality. The "things" in reality have attributes and behaviors. For instance, a human being often has arms and legs, hair color, ethnicity, and can often Speak and Walk.

Speaking and Walking can come in different varieties, such as what language one is speaking, or the speed or manner at which one is walking.

Human Beings often have interactions with other types of "things," whether they be animals, other humans, other living organisms, or inanimate objects. There are themes in reality that often need a way to be represented, such as interactions between "things," categorization of things, etc. Consider business processes that go on in our organization. There exists very complicated "business logic" that needs to get represented in the software that our organization uses.

Object Oriented programming provides a means to accurately represent these "real world concepts" and "business logic".

--> This statement is usually sufficient to stave off their curiosity (or perhaps bores them to tears), but if they have more questions, the above statement (I believe) lays a decent foundation for where the conversation can go. I don't really think that the non-technical person is concerned too much with technical terminology such as "Abstraction," "Composition," "Polymorphism," etc, but if they are, the language I used in the canned statement allows me to pull examples based on it.

Answer 4

I always learnt OOP like this:

You have a clock, and it tells the time - well, in programming you put all the code and stuff you have to do all together (sounds pretty obvious, but people didn't used to do this way back in the early days). Anyway, that's called encapsulation.

Now you've got a clock thing, you might want an alarm clock - well, once you've got all the stuff together you can add things to it to make it do more - like set the alarm and make it ring. This is called inheritance.

Also, you look at the clock I have on my wrist, but you can other clocks that look different like a grandfather clock or a digital clock. It appears different, but it's still a clock - well, that's called polymorphism.

And there you have the 3 corners of object-oriented programming. All the rest is just coding.

Answer 5

I'd just tell them to sign up for a course in OOP if they really want to understand it.

I mean, all those analogies like Car.startEngine(); are, let's face it - pure rap. When I was first into OOP many years ago, I found these to only abstract the domain even further.

Instead of just explaining that OOP is about managing complexity of procedural languages, almost 80% of programming book authors assume that programmers are clueless idiots who need to be spoken in simple (see the irony here?) terms.

Yes, it's perfectly normal to go with explaining Lists and Vectors, because that's what we mostly work with, not Car.Engine and PoliceMan.Arrest (unless you are a game dev, but then again, you still must have had your share of the former).

Back to the topic, I would just tell them, I create untangible objects that exist purely in the programmer's mind, for the purpose of payroll processing/game play/space shuttle navigation, etc.

If they still have questions, stop discussing, because it ain't worth it. Most people fail at imagining abstract notions and need examples for just about everything (which means more simplification/specialization of the actual topic, really).

Answer 6

I talked about a conversation I had with my wife about this very thing, in this answer here: https://softwareengineering.stackexchange.com/questions/45464/how-to-convince-non-programmer-his-notions-about-computers-are-wrong/45467#45467

EDIT: The question I answered there got moderated away, so I'll reprise my answer here.

Sitting in a restaurant with my wife, she asked me "What does Object Oriented mean?"

I started bloviating about code reuse and encapsulation and polymorphism, and at some point I realized her eyes were terminally glazed over.

So I grabbed a Splenda packet out of the container. I said, "Here's an object. What are its properties?"

She said, "It's rectangular, it's made of paper, it contains splenda, it's blue, it has printing on it."

I picked up a sugar packet. "What does it have in common with this one?"

She said, "The rectangularness, the paper, that there is printing."

I said, "What about that they both contain something sweet?"

She said, "Sure."

I said, "So these are both instances of what we might call an abstract sweetener packet. A platonic ideal sweetener packet, if you like."

She said, "Sure."

I said, "And each one has properties inherited from the abstract packet, and then variations on that that are specific to its type of thing."

She said, "Right. Oh! And if I wanted to make, like, a Saccharine packet, I'd take the generic one, and set the details about it for the Saccharine, and then I'd have that!"

I said, "Bingo: Object Oriented Programming."

You and I know she just intuited her way to the Factory design pattern. Whatever. It illustrates inheritance, encapsulation, object class identity... Good stuff.

Answer 7

This question seems a candidate for being closed, nevertheless...

Like most things, OOP is actually very simple to explain at a conceptual level. Programmers model objects; and:

• objects have state (fields/data members)
• objects have actions (methods/functions)
• objects build upon each other (inheritance)

These are hundreds of finer details, sure. But if you're just trying to give someone the 10-second overview, I think that's a good start. Are there more specifics concepts you're having trouble explaining?

Answer 8

The Mobile Phone example:

Imagine you are a factory owner, you want to describe a generic phone

• Step 1: List this generic phones properties eg: height, weight, colour, etc
• Step 2: List this generic phones functions eg: make call, receive call, send sms etc

Now that you have your generic "blueprint" create me the following phones:

Phone 1:

• Height-> 102mm

• Weight-> 85g

• Colour-> Pink

Phone 2:

• Height-> 125mm

• Weight-> 96g

• Colour-> Red

Answer 9

I think the best way to explain to a non-technical type about OOP is to relate it to them.

Essentially OOD & OOP want you to think about the system you are designing and implementing as a world of interacting things.

So lets, for the sake of argument (which never goes well on the internet), say you're explaining to a refuse collector about OOD&P. His name is Bob. You used to go to school with him 15 years ago, you've bumped into him at a bar, and you're both feigning interest in each other's lives.

"So, John, you say you're a programmer. My nephew is into all that nonsense. Keeps going on about object orientated programming, or something. What's all that about?" Note that Bob is British from the way he misspells oriented.

"Well, Bob," you reply, cringing at orientated. "It's quite simple really. You collect refuse, right? What, generally do you in your job?"

"Well, I follow the van around town picking up rubbish and putting it in the van," replies Bob, quizzically.

"Excellent. Well, imagine I'm writing a programme to simulate that. In object oriented design the first step is to determine what objects there are. In your job there seem to be streets, bins, you and the van. Those are our objects. Next we need to know what behaviours each object performs. I'm not sure how it works in the real world, but lets assume that you are told about street that need clearing. There is one behaviour - streets notify when they need clearing. That means that something needs to be listening out for streets that need clearing. I guess since you follow the van, the van will listen out for streets that need clearing - that's two. A third is, obviously, you follow the van. Another is you put rubbish in the van. You also spot if a bin is full. I guess the van will need to notify you when it is full, and you will need to listen out for that. Those are our behaviours. That's essentially all you need for the design. Object oriented programming is essentially how you implement the design. It differs from language to language."

Bob has fallen asleep in his beer. You walk away.

Answer 10

I like the car example for explaining inheritance (I tend to use animals rather than vehicles but it's the same idea) but for explaining how an object-oriented program works I refer to an analogy I once read on Chris Crawford's website: the program is like a really efficient bureaucracy. All the different objects in the program are like the different departments in a bureaucracy; each department has it's own designated tasks, they have well defined inputs (who to talk to and what forms to fill out,) and other departments often don't know that much about what goes on inside. HR is like an abstract factory, IT is a singleton, etc.

Getting an error message because you typed the wrong thing in a computer program is exactly like filling out the form wrong to submit to an office.

Answer 11

OOP is a gross simplification if anything - an abstraction - of human thought process and understanding of the world to project functionality into a digital "void" to mimic familiar processes and classifications digitally. It is, in many regards, more about our primitive language state than us "thinking more like computers".

If programming mimicked reality or human thought it would be far more organic, chaotic and haphazard in nature - lateral even. Instead we simplify reality into baby steps, "2+2 logic", crude categories, re-usable little tools and prehistoric reasoning.

We're still trying to work out how to download our thoughts and desires into a protocol and common language and I for one think historians will be fascinated with its sophisticated crudeness one day - like we now see hieroglyphs. It's not "clever" at all - it simply highlights how we can't easily explain how we decide or understand even the simplest of things. Computing is still at the "a dog is a dog because it's not a cat" level of thought evolution - it's millennia behind even basic spoken language.

Answer 12

There's two kinds of wizards. There's the guy who makes specific things happen with magic words. He's got a word for summoning fire. He's got a word for making a frozen chicken appear out of thin air. And another word for creating a pot of force (I prefer my force green, glowy, and translucent) full of friolating goodness. With the right application of his words he can produce a fried chicken.

And then there's the OOP wizard. Who just summons an imp who knows how to go the grocery store, buy a chicken (or ingredients for any other food you want him to prepare), cook it, and serve you dinner. OOP Wizard doesn't have to tell his imp how to do it. He just needs to let him know what he wants which in this case is fried chicken. Not only that, the OOP wizard can summon other minions to tell his imp-chef what to do.

So, the incantation guy impresses at parties but the OOP wizard is the one you want when you're going to start a magic restaurant with a bunch of characters (like say, a pissed off unicorn waiter, and a troll floor manager) who all have to work together. If you try to invoke every step of the problem of solving "restaurant" you can easily get tangled up in the details and it's really easy to make mistakes. The OOP wizard pre-trains his minions to sort out the details for him so he can just focus on solving the bigger problem by having his people interact.

Not to mention it's easier to re-use your chef-imp for your grade school cafeteria problem then it is to separate all the junk you might or might not re-use when you're doing it all one step at a time by calling words and words that call other sets of words (which will get more an more numerous as you have to handle a greater variety of problems).

To be fair, with very, very careful application, the incantation wizard can get it all done as fast as the OOP wizard. He can break things down in the right way such that calling the right spells requires no more work on his part than the OOP wizard. But the work is much harder to understand or duplicate and much harder to re-use large portions of because it's all tied together for one specific complex problem.