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

<ul>
<li><a href="https://www.youtube.com/watch?v=XCEtl9CfbAU" rel="noreferrer">https://www.youtube.com/watch?v=XCEtl9CfbAU</a></li>
<li><a href="https://www.youtube.com/watch?v=exGtj4jjbco" rel="noreferrer">https://www.youtube.com/watch?v=exGtj4jjbco</a></li>
</ul>

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

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

<p>Then you have a nice segue into constructing an Object together.</p>

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

CC BY-SA 3.0
2017-05-25T03:00:34.053Z
The two best _objects_ to use are "vehicles" and "computers." The benefit to both is that they, commonly, have inner workings (private methods and data) that are not exposed by the interface. The "vehicle" class can start with a bicycle (no motor) and move on to cars/trucks, and just in case "wheels" gets thought of as a base class attribute, what about the helicopter? The benefit of the computer as a sample object is that it should already be in the classroom and easily compared to the smart phone and tablets that students are likely to have available as well.
Gypsy Spellweaver
CC BY-SA 3.0
2017-05-24T21:26:45.183Z
2017-05-24T21:26:45.183Z
Ben I.
<p>I have thought of different sizes, shapes and colors of boxes.</p>

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

<p>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.</p>

<p>Requested examples:</p>

<p><strong>Inheritance:</strong> 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.</p>

<p><strong>Instances:</strong> 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.</p>

<p><strong>Properties:</strong> 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.</p>

<p>More examples tomorrow, I'm going to bed.</p>

CC BY-SA 3.0
2017-05-24T23:50:36.540Z
I use a similar analogy for variables. Could you elaborate a bit on how you might use boxes to model inheritance, instance methods, class methods, and properties? I think there's more here that could be expanded upon.
Peter
CC BY-SA 3.0
2017-05-26T15:43:17.457Z
@OldBunny2800: There's no need to include 'EDIT:' in your post—see [What's wrong with putting “EDIT: …” in the body of a post?](https://meta.stackexchange.com/questions/202472/whats-wrong-with-putting-edit-in-the-body-of-a-post). Users can check the revision history to see when you edited, so you needn't clutter your post with `EDIT:` if you don't want.
Aurora0001
CC BY-SA 3.0
2017-05-24T21:34:40.177Z
2017-05-26T21:13:30.213Z
2017-05-26T21:13:30.213Z
AAM111
<p>A good analogy might use animals and their classification.</p>

<p>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.</p>

<p>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.</p>

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

CC BY-SA 4.0
2022-01-13T15:53:08.280Z
Note that in the Linnaeus classification, which is treelike, all of the nodes are abstract except the leaf nodes. In Java you can use interfaces for that. But it isn't a good example of concrete inheritance.
Buffy
CC BY-SA 3.0
2017-06-19T12:43:06.613Z
And then you are throwing away languages which forbid multiple inheritance
Display Name
CC BY-SA 3.0
2017-05-28T18:41:51.517Z
A domestic cat is a feline and a tiger is a feline. I apologize for using cat and feline interchangeably here.
xuq01
CC BY-SA 3.0
2017-05-25T02:25:27.287Z
2017-05-25T02:25:27.287Z
xuq01
<pre><code>Wheeled vehicles
 |-human-propelled
 ||- unicycle
 ||- bicycle
 ||- tricycle
 |-animal-propelled
 ||- cart
 ||- carriage
 ||- ...
 |- motor-propelled
 ||- motorcycle
 ||- car
 ||- ...
</code></pre>

<p>This allows you to explore both subclassing and composition.</p>

CC BY-SA 3.0
2017-05-25T11:56:57.047Z
2017-05-25T14:38:21.533Z
2017-05-25T14:38:21.533Z
G. Ann - SonarSource Team
<p>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...</p>

<p>Anybody can easily relate to this cause we are all human.</p>

CC BY-SA 3.0
2017-05-25T15:04:21.117Z
I use this one too. It goes Thing > Living Thing > Animal > Mammal > Human > Student > High School Student > Computer Science Student > 3rd Period Computer Science Student. We add in properties and methods at each level when we talk about inheritance.
Ryan Nutt
CC BY-SA 3.0
2017-05-24T21:37:16.057Z
2017-05-24T21:37:16.057Z
Manav Dubey
<p>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. </p>

<p>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. </p>

<p>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. </p>

<p>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. </p>

<p>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. </p>

CC BY-SA 3.0
2017-06-24T16:55:12.503Z
2017-06-24T16:55:12.503Z
Buffy
<p>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.</p>

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

CC BY-SA 3.0
2017-07-22T22:47:25.340Z
Hello, and welcome to Computer Science Educators! Thanks for your answer; I hope to continue seeing you around the site.
auden
CC BY-SA 3.0
2017-07-22T22:30:28.293Z
2017-07-22T22:30:28.293Z
Jim Huggins
<p>I'm in the midst of a PennX course on edX called <a href="https://courses.edx.org/courses/course-v1:PennX+SD1x+2T2017/info" rel="nofollow noreferrer">Software Development Fundamentals</a> taught using Java, and they gave the analogy of parts of speech.</p>

<ul>
<li>Objects -> Nouns</li>
<li>Methods -> Verbs (i.e. Actions)</li>
</ul>

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

<ul>
<li>Properties -> Adjectives</li>
<li>Class and (instance or subclass) -> Common noun and proper noun</li>
</ul>

<p>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.</p>

<p>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 <code>instanceof()</code> as students will hopefully see relatively intuitively that a Civic is quite clearly a car, but a car is not necessarily a Civic. </p>

CC BY-SA 3.0
2017-05-27T21:38:35.693Z
2017-05-27T21:38:35.693Z
Peter
<p>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 <code>Good guy</code> and <code>Bad guy</code> classes. </p>

<p>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...</p>

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

CC BY-SA 3.0
2017-05-25T16:59:02.830Z
2017-05-25T16:59:02.830Z
AlG
<p>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.</p>

<p><strong>Procedural solutions</strong>: moving pieces of data around and manipulating them. I go back to a <em>cooking analogy</em> and compare programs to <em>recipes</em>: 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).</p>

<p><strong>OOP</strong>: I draw heavily from Yegge's <a href="https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html" rel="nofollow noreferrer">Kingdom of the Nouns</a> 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."</p>

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

<ul>
<li><p>The <code>Whale</code> class is a category of animal, whereas <code>bruce = Whale()</code> and <code>sally = Whale()</code> are both instances of <code>Whale</code>. The analogy is that instances are like <em>individuals</em> (the human-like names are very intentional).</p>

<p>I also tap into a secondary analogy: a class is like a <em>cookie cutter</em> 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. </p></li>
<li><p>Member functions are <em>verbs</em> (analogous to objects being Nouns): <code>bruce.eat(fish)</code> and <code>sally.sing()</code></p>

<p>Secondary analogy: methods are like <em>little remora</em> who are attached to the whale and do stuff for it, like <code>sally.clean()</code>. All verbs only exist if they are attached to some noun.</p></li>
<li><p>Data members are data that relate to the noun. The extension of the analogy is that they are <em>adjectives</em> that describe the whale: <code>bruce.weight_in_tons = 200</code></p>

<p>Secondary analogy: these are data <em>inside the whale</em>, 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.</p></li>
<li><p>Inheritance: as others have suggested, the analogy is <em>animal taxonomy</em>. A <code>BlueWhale</code> is a <code>Whale.</code> All <code>BlueWhale</code> have a blowhole (like other wales) but they also have baleen, etc.</p></li>
</ul>

<p>Its not a perfect analogy, but I get mileage out of it.</p>

CC BY-SA 3.0
2017-06-08T04:33:37.143Z
2017-06-08T04:33:37.143Z
GermaneDork
<p>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.)</p>

CC BY-SA 3.0
2017-06-14T12:30:07.017Z
2017-06-14T12:30:07.017Z
Ari
<p>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.</p>

CC BY-SA 3.0
2017-07-22T08:36:00.417Z
@nocomprende Oh cool, it looks like I groked it.
ctrl-alt-delor
CC BY-SA 3.0
2017-05-25T17:28:12.770Z
2017-05-25T17:28:12.770Z
ctrl-alt-delor
<p>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.</p>

<p>Therefore classes are used to model subjects and objects.</p>

<p>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.</p>

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

CC BY-SA 3.0
2017-07-22T08:47:53.743Z
2017-07-22T08:47:53.743Z
ctrl-alt-delor
<p>I asked a similar question <a href="https://cseducators.stackexchange.com/questions/6709/some-real-practical-example-to-teach-object-oriented-concepts-and-programming-i">Some real practical example to teach object-oriented concepts and programming (in python)</a></p>
<p>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.</p>
<p>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 &quot;<a href="https://www.coreycleary.me/what-is-the-difference-between-controllers-and-services-in-node-rest-apis/" rel="nofollow noreferrer">What is the difference between Controllers and Services in Node REST API's?</a>&quot; explains the manager/worker example very well, so I just borrow his/her words</p>
<blockquote>
<p>If you think about what the manager's role is, he/she typically:</p>
<ol>
<li>manages the incoming work requests</li>
<li>decides which worker should do the work</li>
<li>splits up the work into sizable units
...
but does not do the work himself/herself (again, using a basic
stereotype here!)</li>
</ol>
</blockquote>
<blockquote>
<p>And, a worker typically:</p>
<ol>
<li>receives the request from the manager</li>
<li>figures out the individual details involved in completing the request</li>
<li>is generally only concerned with the tasks he/she has to complete</li>
<li>not responsible for making decisions about the &quot;bigger&quot; picture</li>
</ol>
</blockquote>
<blockquote>
<p>The overarching theme is that the manager/controller receives the work, decides who should do it...</p>
</blockquote>
<p>So manager/worker works together (composition) to do the job.</p>
<p>--- update ---</p>
<p>These 3 Q&amp;A may be too hard for the beginner but they can be served for the follow up questions.</p>
<ol>
<li><p><a href="https://stackoverflow.com/questions/1866794/naming-classes-how-to-avoid-calling-everything-a-whatevermanager">Naming Classes - How to avoid calling everything a &quot;Manager&quot;?</a>  The legendary &quot;<a href="https://martinfowler.com/bliki/TwoHardThings.html" rel="nofollow noreferrer">two hard things in Computer Science</a>&quot;</p>
</li>
<li><p><a href="https://softwareengineering.stackexchange.com/questions/129537/can-manager-classes-be-a-sign-of-bad-architecture">Can manager classes be a sign of bad architecture?</a> Of course it depends.</p>
</li>
<li><p><a href="https://softwareengineering.stackexchange.com/questions/419122/does-oop-overemphasize-the-importance-of-noun-and-thus-put-action-verb-in-the-le">What we should use instead of a &quot;manager&quot; class in a good OOP design?</a> Short answer if a manager assumes too many responsibilities split it. Again this is also a good analogy in real life.</p>
</li>
</ol>

CC BY-SA 4.0
2022-01-13T04:13:09.303Z
2022-01-14T05:11:15.973Z
2022-01-14T05:11:15.973Z
Qiulang 邱朗
<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-06-22T10:14:11.317Z
While this is certainly an interesting take on how to teach OO, it isn't an analogy and so doesn't exactly answer the question. I think that it brings value to the question anyways, so +1.
thesecretmaster
CC BY-SA 3.0
2017-06-22T10:33:14.080Z
@thesecretmaster I do consider it an analogy. Just that the analogy is behavior. And how best to encode behavior than with code?
Euphoric
CC BY-SA 3.0
2017-06-22T08:57:37.450Z
2017-06-22T08:57:37.450Z
Euphoric
<p>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 &quot;a thing that you can ask to do things&quot;.</p>
<p>Since I teach programming to science-y students I use examples from math. For instance a <code>Point</code> 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.</p>
<p>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.</p>
<p>And then you go on to make a <code>Line</code> object that comes from two Points, rather than four reals <code>x1,x2,y1,y2</code>, et cetera.</p>

CC BY-SA 4.0
2022-01-13T20:35:13.320Z
Yes, objects are bundles of behavior. The public methods define that behavior. But if you implement objects with other objects at a lower level, then things composed of things is still a valid way to think. But each is defined by its behavior, not by its implementation structure.
Buffy
CC BY-SA 4.0
2022-01-13T20:45:06.650Z
@Buffy Agree, "things composed of things" smacks of a data-oriented way of looking at things. However, each level of composition is an abstraction level, with its own vocabulary of public methods. Teaching abstraction levels is a Good Thing btw, and OO programming is a great way to do that. (In my above example the levels are of course not strictly contained because you can ask for the distance of a Point to a Line.)
Victor Eijkhout
CC BY-SA 4.0
2022-01-14T04:46:34.857Z
Regarding things/actions I asked a question at https://softwareengineering.stackexchange.com/questions/419122/does-oop-overemphasize-the-importance-of-noun-and-thus-put-action-verb-in-the-le  even though it was closed and has 2 delete votes I still think my question is valid.
Qiulang 邱朗
CC BY-SA 4.0
2022-01-14T14:16:34.423Z
@Qiulang邱朗 Interesting stuff. I wonder how we can move this discussion to chat.
Victor Eijkhout
CC BY-SA 4.0
2022-01-10T18:57:26.233Z
2022-01-13T20:26:01.150Z
2022-01-13T20:26:01.150Z
Victor Eijkhout
<p>Another analogy which comes to mind is buildings.</p>

<p><strong>Abstraction</strong>: You never build a building. You build a house, an apartment building or an office building. </p>

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

<pre><code>interface Habitat;
abstract class Building;
</code></pre>

<p>and then</p>

<pre><code>class ApartmentBuilding extends Building implements Habitat{...
</code></pre>

<p>And this shows the basic construct (he, unintended pun) of OOP. </p>

<p>A singleton can be <code>EmpireStateBuilding</code>. 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 <strong>an</strong> <code>EmpireStateBuilding</code> would create one single <code>EmpireStateBuilding</code>. So it's a singleton.</p>

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

<p>So this analogy covers most of what's discussed when teaching OOP.</p>

CC BY-SA 4.0
2022-01-14T19:53:33.770Z
I disagree with your singleton example. Why is the Empire State Building a class, rather than an object? Or conversely, why isn't *every* building a singeton? Why isn't every object of every class a singleton?
Victor Eijkhout
CC BY-SA 3.0
2017-06-28T10:07:16.193Z
2017-06-28T10:07:16.193Z
ItamarG3
<p>I've <em>got</em> 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 <a href="https://xkcd.com/1425/" rel="noreferrer">this was easy</a>).</p>

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

<blockquote>
  <p>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).</p>
</blockquote>

<p>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.</p>

<ul>
<li>It has output: <code>bool isOn()</code></li>
<li>It has a method of supplying input: <code>toggle()</code></li>
<li>Underneath it has an implementation of what <code>toggle()</code> does and how that affects the return value of <code>isOn()</code></li>
</ul>

<p>Buttons can also be described in this manner:</p>

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

<p>A knob also has similar features, although different types are involved:</p>

<ul>
<li>It has output: <code>float getValue()</code></li>
<li>It has input: <code>twistTo(float v)</code></li>
<li>Underneath it has an implementation</li>
</ul>

<p>But here's where it gets interesting:</p>

<p>What happens if we define an object that implements <em>both</em> <code>Knob</code> <strong>and</strong> <code>Button</code>? We should expect the following description:</p>

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

<p>What do we end up with?</p>

<p><a href="https://i.sstatic.net/YVp2z.png" rel="noreferrer"><img src="https://i.sstatic.net/YVp2z.png" alt="A timer switch"></a></p>

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

<p>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.</p>

<p>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...</p>

<p>And then...you can get to events. Instead of treating the wires in the analogy as hard links in code (<code>while(switch.isOn()) { ... }</code>), 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 <em>their</em> implementation dictates (<code>switch.addListener(this.doWhenToggled)</code>).</p>

<p>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 <code>vehicles</code> drive, fly, and float and just disable the ones we don't need!) rather than through a composition of interfaces (say, <code>FloatPlane extends BaseAircraft implements IWaterCraft</code>).</p>

<p>I know that sort of thinking messed <em>me</em> up for a number of years. Heck, I'm <em>still</em> 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 <em>AND</em> cars" because they both share some property that doesn't exist in the common class (and shouldn't) and I have to refactor.</p>

<p>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 <em>god</em> of these , offering an astounding <em>fourteen</em> 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."</p>

CC BY-SA 3.0
2017-06-22T18:44:28.813Z
Welcome to CSE! This is a gorgeous answer, and I hope we hear more from you in the future!
Ben I.
CC BY-SA 3.0
2017-06-22T18:52:18.603Z
@BenI. I saw another question on the Hot Network Questions the other day but this one pulled me out of the woodwork. I will probably be more of a lurker, though!
Draco18s no longer trusts SE
CC BY-SA 3.0
2017-06-22T18:57:12.127Z
More's the pity. Pipe in whenever you get inspired ;-)
Ben I.
CC BY-SA 3.0
2017-06-22T19:03:19.023Z
@BenI. I'm no educator, but I'll certainly speak up when I see something that I can talk about. My CS education was so incomplete as to be almost useless.
Draco18s no longer trusts SE
CC BY-SA 3.0
2017-06-29T17:23:19.687Z
Your third-and-second-to-last paragraphs are really important. The "zoo" type introductions to OO are, in my opinion, extremely destructive. They can mess up how people think about OO design in a subtle way for a really long time. Switches, lights, and anything where there's a natural input, output and desired behavior are so much better than "a cat is an animal, so Cat.MakeNoise() should return 'meow'".
Ben Aaronson
CC BY-SA 3.0
2017-06-29T17:23:23.470Z
This can also lead on really nicely to encapsulation and abstraction as concepts. Note that the wiring from a switch to a lightbulb isn't accessible to the user. And that not knowing whether a class member should be public or private is like not knowing whether part of a TV should be on the inside or outside!
Ben Aaronson
CC BY-SA 3.0
2017-06-29T17:33:38.917Z
Exactly @BenAaronson . It's not a *perfect* analogy as the programmer often is the electrician, messing about with the wires, but the general idea holds up pretty well.
Draco18s no longer trusts SE
CC BY-SA 3.0
2017-06-22T17:51:31.893Z
2017-06-22T17:51:31.893Z
Draco18s no longer trusts SE
<p>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.</p>

<p>A similar question exists <a href="https://stackoverflow.com/questions/3141957/a-good-object-oriented-analogy">on Stack Overflow</a>. I would like to duplicate it here because on Stack Overflow it was closed an "Not Constructive."</p>

<p>It also exists <a href="https://softwareengineering.stackexchange.com/questions/34584/how-to-explain-oop-concepts-to-a-non-technical-person">on Software Engineering</a>, 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.</p>

CC BY-SA 3.0
2017-06-28T11:02:40.313Z
In the essence, OOP is based on messages and contracts, an object pass a message to another, which will eventualy return a value, whatever it does within in process is unkwown by the sender of the message. Otherwise a good way to restrict the scope of your question would be to limit yourself to encapsulation, polymorphism and inheritance. Which is the basis of OOP. Patterns (singleton) that come as specific usage of those bases is a somewhat another subject that come after.
Walfrat
CC BY-SA 3.0
2017-05-27T23:44:03.950Z
I'm voting to close as too broad, because there's no such thing as “the” object oriented paradigm. A lot of concepts hide behind these words, they're different concepts depending on who's talking and what language they treat as the one true way of doing things, and different analogies will be needed for these different concepts.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-05-27T23:51:14.803Z
It is broad, but I wouldn't say it's too broad. Just because there is no "correct" answer doesn't mean that it's too broad. There are many different ways to kill a process, each with upsides and downsides, but they all could be covered by one question.
thesecretmaster
<object-oriented-paradigm><teaching-analogy>
What is a good analogy for the Object Oriented paradigm?
# What is a good analogy for the Object Oriented paradigm?

(Asked by: username_0 on 2017-05-24)

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](https://stackoverflow.com/questions/3141957/a-good-object-oriented-analogy). I would like to duplicate it here because on Stack Overflow it was closed an "Not Constructive."

It also exists [on Software Engineering](https://softwareengineering.stackexchange.com/questions/34584/how-to-explain-oop-concepts-to-a-non-technical-person), 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.

**Tags:** object-oriented-paradigm, teaching-analogy

> **Comments:**
> **username_2**: I'm voting to close as too broad, because there's no such thing as “the” object oriented paradigm. A lot of concepts hide behind these words, they're different concepts depending on who's talking and what language they treat as the one true way of doing things, and different analogies will be needed for these different concepts.  
> **username_0**: It is broad, but I wouldn't say it's too broad. Just because there is no "correct" answer doesn't mean that it's too broad. There are many different ways to kill a process, each with upsides and downsides, but they all could be covered by one question.  
> **username_1**: In the essence, OOP is based on messages and contracts, an object pass a message to another, which will eventualy return a value, whatever it does within in process is unkwown by the sender of the message. Otherwise a good way to restrict the scope of your question would be to limit yourself to encapsulation, polymorphism and inheritance. Which is the basis of OOP. Patterns (singleton) that come as specific usage of those bases is a somewhat another subject that come after.  

---

## 18 answers

### Answer by username_24 on 2017-06-22. Score: 16

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](https://xkcd.com/1425/)).

username_3'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?

[![A timer switch](https://i.sstatic.net/YVp2z.png)](https://i.sstatic.net/YVp2z.png)

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

> **Comments:**
> **username_3**: Welcome to CSE! This is a gorgeous answer, and I hope we hear more from you in the future!  
> **username_24**: @BenI. I saw another question on the Hot Network Questions the other day but this one pulled me out of the woodwork. I will probably be more of a lurker, though!  
> **username_3**: More's the pity. Pipe in whenever you get inspired ;-)  
> **username_24**: @BenI. I'm no educator, but I'll certainly speak up when I see something that I can talk about. My CS education was so incomplete as to be almost useless.  
> **username_25**: Your third-and-second-to-last paragraphs are really important. The "zoo" type introductions to OO are, in my opinion, extremely destructive. They can mess up how people think about OO design in a subtle way for a really long time. Switches, lights, and anything where there's a natural input, output and desired behavior are so much better than "a cat is an animal, so Cat.MakeNoise() should return 'meow'".  
> **username_25**: This can also lead on really nicely to encapsulation and abstraction as concepts. Note that the wiring from a switch to a lightbulb isn't accessible to the user. And that not knowing whether a class member should be public or private is like not knowing whether part of a TV should be on the inside or outside!  
> **username_24**: Exactly @BenAaronson . It's not a *perfect* analogy as the programmer often is the electrician, messing about with the wires, but the general idea holds up pretty well.  

---

### Answer by username_8 on 2017-05-25. Score: 8

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.

> **Comments:**
> **username_8**: A domestic cat is a feline and a tiger is a feline. I apologize for using cat and feline interchangeably here.  
> **username_10**: And then you are throwing away languages which forbid multiple inheritance  
> **username_9**: Note that in the Linnaeus classification, which is treelike, all of the nodes are abstract except the leaf nodes. In Java you can use interfaces for that. But it isn't a good example of concrete inheritance.  

---

### Answer by username_3 on 2017-05-24. Score: 5

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.

> **Comments:**
> **username_4**: The two best _objects_ to use are "vehicles" and "computers." The benefit to both is that they, commonly, have inner workings (private methods and data) that are not exposed by the interface. The "vehicle" class can start with a bicycle (no motor) and move on to cars/trucks, and just in case "wheels" gets thought of as a base class attribute, what about the helicopter? The benefit of the computer as a sample object is that it should already be in the classroom and easily compared to the smart phone and tablets that students are likely to have available as well.  

---

### Answer by username_5 on 2017-05-24. Score: 5

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.

> **Comments:**
> **username_6**: I use a similar analogy for variables. Could you elaborate a bit on how you might use boxes to model inheritance, instance methods, class methods, and properties? I think there's more here that could be expanded upon.  
> **username_7**: @OldBunny2800: There's no need to include 'EDIT:' in your post—see [What's wrong with putting “EDIT: …” in the body of a post?](https://meta.stackexchange.com/questions/202472/whats-wrong-with-putting-edit-in-the-body-of-a-post). Users can check the revision history to see when you edited, so you needn't clutter your post with `EDIT:` if you don't want.  

---

### Answer by username_11 on 2017-05-25. Score: 4

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 by username_12 on 2017-05-24. Score: 4

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.

> **Comments:**
> **username_13**: I use this one too. It goes Thing > Living Thing > Animal > Mammal > Human > Student > High School Student > Computer Science Student > 3rd Period Computer Science Student. We add in properties and methods at each level when we talk about inheritance.  

---

### Answer by username_9 on 2017-06-24. Score: 4

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 by username_16 on 2017-05-25. Score: 4

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 by username_14 on 2017-07-22. Score: 3

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

> **Comments:**
> **username_15**: Hello, and welcome to Computer Science Educators! Thanks for your answer; I hope to continue seeing you around the site.  

---

### Answer by username_6 on 2017-05-27. Score: 3

I'm in the midst of a PennX course on edX called [Software Development Fundamentals](https://courses.edx.org/courses/course-v1:PennX+SD1x+2T2017/info) 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 by username_17 on 2017-06-08. Score: 2

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](https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html) 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 by username_18 on 2017-06-14. Score: 2

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 by username_19 on 2017-05-25. Score: 2

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.

> **Comments:**
> **username_19**: @nocomprende Oh cool, it looks like I groked it.  

---

### Answer by username_19 on 2017-07-22. Score: 2

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 by username_20 on 2022-01-13. Score: 2

I asked a similar question [Some real practical example to teach object-oriented concepts and programming (in python)](https://cseducators.stackexchange.com/questions/6709/some-real-practical-example-to-teach-object-oriented-concepts-and-programming-i)

I highly agree with what @username_9 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?](https://www.coreycleary.me/what-is-the-difference-between-controllers-and-services-in-node-rest-apis/)" 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"?](https://stackoverflow.com/questions/1866794/naming-classes-how-to-avoid-calling-everything-a-whatevermanager) The legendary "[two hard things in Computer Science](https://martinfowler.com/bliki/TwoHardThings.html)"
2. [Can manager classes be a sign of bad architecture?](https://softwareengineering.stackexchange.com/questions/129537/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?](https://softwareengineering.stackexchange.com/questions/419122/does-oop-overemphasize-the-importance-of-noun-and-thus-put-action-verb-in-the-le) Short answer if a manager assumes too many responsibilities split it. Again this is also a good analogy in real life.


---

### Answer by username_21 on 2017-06-22. Score: 2

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.

> **Comments:**
> **username_0**: While this is certainly an interesting take on how to teach OO, it isn't an analogy and so doesn't exactly answer the question. I think that it brings value to the question anyways, so +1.  
> **username_21**: @username_0 I do consider it an analogy. Just that the analogy is behavior. And how best to encode behavior than with code?  

---

### Answer by username_22 on 2022-01-10. Score: 2

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.

> **Comments:**
> **username_9**: Yes, objects are bundles of behavior. The public methods define that behavior. But if you implement objects with other objects at a lower level, then things composed of things is still a valid way to think. But each is defined by its behavior, not by its implementation structure.  
> **username_22**: @username_9 Agree, "things composed of things" smacks of a data-oriented way of looking at things. However, each level of composition is an abstraction level, with its own vocabulary of public methods. Teaching abstraction levels is a Good Thing btw, and OO programming is a great way to do that. (In my above example the levels are of course not strictly contained because you can ask for the distance of a Point to a Line.)  
> **username_20**: Regarding things/actions I asked a question at https://softwareengineering.stackexchange.com/questions/419122/does-oop-overemphasize-the-importance-of-noun-and-thus-put-action-verb-in-the-le  even though it was closed and has 2 delete votes I still think my question is valid.  
> **username_22**: @Qiulang邱朗 Interesting stuff. I wonder how we can move this discussion to chat.  

---

### Answer by username_23 on 2017-06-28. Score: 1

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.

> **Comments:**
> **username_22**: I disagree with your singleton example. Why is the Empire State Building a class, rather than an object? Or conversely, why isn't *every* building a singeton? Why isn't every object of every class a singleton?  

---

