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: http://programmers.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.