<p>It depends on the goal.  For an initial, highly intuitive brush, I've frequently used animals. They share some advantages over cups.</p>
<ol>
<li>There are a <em>lot</em> of them.</li>
<li>They already come pre-categorized into class trees thanks to hundreds of years of labor by thousands of people.</li>
<li>It's not just a good example, it is quite real. Animals utilize genuine inheritance. Racoons are able to produce bile for the same reason that we are, because we inherited the DNA for a gallbladder from our common ancestors, and the behaviors of these organs is essentially the same for both species.<sup>1</sup></li>
<li>Animals don't just do well to explain inheritance, but lend themselves towards a lot more advanced thinking.</li>
</ol>
<p>They clearly lend themselves to inheritance well, because they are genuine manifestations of it in nature. (All mammals growHair(), but along the tree, rodentia's approach would implement that as fur, and the naked mole rat would have to override that yet again.)</p>
<p><em><strong>At this point it's worth noting that I do not advocate sticking to only this example. Once it has been made intuitive, it's time to move on and have students try it in other contexts.</strong></em></p>
<p>The example also readily (happily!) switches over to teaching abstract classes once students are ready. <em>(Earlier we examined a fictional animal system. But there was a bit of a problem before that we didn't delve into. Let's look at this now: I can instantiate a</em> <em><strong>poecilia latipina,</strong></em> <em>but what would it mean to instantiate a fish?? That shouldn't be possible! &quot;Fish&quot; isn't a specific fish, it's an abstract idea of fish...)</em></p>
<p>It also lends itself to interfaces.  <em>(Earlier, we looked at a fictional animal inheritance system.  It had another problem!  We might start with the idea that birds fly, but what of penguins? Or bats? We need a new tool for this action.)</em></p>
<p>If you want them to think deeply about OOP (<em>after</em> they've learned the pieces of it well) have them consider <a href="https://en.m.wikipedia.org/wiki/Carcinisation" rel="nofollow noreferrer">carcinization</a>. How would something like that be represented in OOP? To my taste, there is no fixed answer, but it's an interesting question and lends itself to deeper thinking about both OOP and biology.</p>
<p>#Bad Coding Practice in the Animal Kingdom#</p>
<p>There was an objection in the comments section, pointing out that it is bad practice to have a child's interface become larger than the parent interface. I would strenuously argue that, while this is true, we are still duty-bound to explain what inheritance can do, and in languages like Java and C++, we are able to expand the interface. We must make the mechanics of this as intuitive as the rest.</p>
<p>It's also worth noting that all of this animal stuff probably takes no more than 15 (cumulative!) minutes over three different days. I also heavily lean into good coding practice in my courses, but I do it in many passes.</p>
<p>This is an example from nature. It does not follow good coding style, but that's not necessarily a flaw. It is perfectly reasonable to revisit the animal example later on and talk about why we might not want to allow children to expand interfaces in our own programming projects.</p>
<p><sup>1</sup> You may notice an apparent difference between biological and OOP inheritance in that due to limited lifespan, we are not literally handing our bilirubin to our ancestor in order to make the bile - we instead inherit the mechanism to do it ourselves.  However, I would argue that this is worth mentioning, but not a difference that you would want to lean into too hard in the classroom, as this passing of information up and down the hierarchy breaks OOP's metaphor. We are not meant to even be aware of such cross-generational passing when we use an object in OOP. It is only important briefly when coding the object itself.</p>

CC BY-SA 4.0
2023-03-29T13:59:32.113Z
**Comments have been [moved to chat](https://chat.stackexchange.com/rooms/144945/discussion-on-answer-by-ben-i-what-is-an-example-of-class-inheritance-in-every); please do not continue the discussion here.** Before posting a comment below this one, please review the [purposes of comments](/help/privileges/comment). Comments that do not request clarification or suggest improvements usually belong as an [answer](/help/how-to-answer), on [meta], or in [chat]. Comments continuing discussion may be removed.
Ben I.
CC BY-SA 4.0
2023-03-27T12:02:49.907Z
2023-03-28T13:34:22.473Z
2023-03-28T13:34:22.473Z
Ben I.
<p>Real world examples are good, before you get to coding. Use them first to explain the idea. Then introduce a coding problem: How can we use this idea to simplify this code.</p>
<p>Some languages prevent the most powerful use of this idea. E.g Java only allows multiple inheritance of interfaces. Eiffel, Python (it's a duck), and Rust, don't have this problem.</p>

CC BY-SA 4.0
2023-03-29T23:22:57.193Z
I am aware that python uses duck typing, but I am confused why you wrote something like, "Python (it is a duck)". The Python programming language uses duck typing, but python itself is not a duck-type. An example of duck typing would be a class object which emulates the `list` class by defining all of the following attributes: `append`, `clear`,  `copy`, `count`,  `extend`, `index`, `insert`, `pop`, `remove`, `reverse`, `sort`
Samuel Muldoon
CC BY-SA 4.0
2023-04-04T10:08:21.567Z
@SamuelMuldoon I did not mean to be that literal.
ctrl-alt-delor
CC BY-SA 4.0
2023-05-25T21:48:08.810Z
I agree that real-world examples are useful before students get into writing syntactically worry code in order to explain the idea of inheritance. The question is, what is a specific example of a real-world example? Maybe `souring powder` and `light-bulbs` inherit from inedible items? I am not sure that is an example students would find interesting.
Samuel Muldoon
CC BY-SA 4.0
2023-05-27T12:07:12.190Z
@SamuelMuldoon python can quack, so it is a duck (according to duck-typing).
ctrl-alt-delor
CC BY-SA 4.0
2023-05-27T12:09:46.177Z
@SamuelMuldoon a class does not implement the set of things that are not in another set. E.g. you can't make a class `not edible`. You could, but what methods would it have? `don't eat`?
ctrl-alt-delor
CC BY-SA 4.0
2023-05-27T12:12:07.133Z
`souring powder` is that `saw dust`, the dust that comes from sawing wood. That is `edible`, they put it on some `edible` products. What it is not is `food`.
ctrl-alt-delor
CC BY-SA 4.0
2023-03-29T09:48:54.957Z
2023-03-29T09:48:54.957Z
ctrl-alt-delor
<p>This is a harder question than it seems if you want to get across the idea that a type hierarchy should contain variations but with the <em>same interface</em>. If the interface gets extended as you go down the hierarchy then you have the problem that you too-often need to do type casting of variables (Java) or risk runtime failure (Python) if you make certain assignments and then try to message the referenced object.</p>
<p>In particular, I try to get this idea across early, since if it isn't taught and the opposite process is, it can be very hard to unlearn bad (IMO) habits and replace them. It was for me in fact.</p>
<p>It is the same problem you get using too many if-statements and the program becomes so ad-hoc that it is difficult to understand, much less modify.</p>
<p>Your example of cups is pretty good, I think, since cups should all be able to have the same usages (think UI). So, I'd try to think about things in real life that are basically alike, but have variations.</p>
<p>Clothing fits that in some ways. There are many variations on &quot;skirt&quot; or &quot;pants&quot; or &quot;jacket&quot; that all interface to the world in the same way. They have color, closure methods, sizes, etc. but a visit to a clothing store will give you a sense of the variations.</p>
<p>I'll also note that all of the keys on my current keyboard have the same &quot;interface&quot; but all perform a different task.</p>
<p>Smartphones are pretty generic, actually, in spite of the marketing hype. Mine is probably a lot like yours.</p>
<p>Vehicle is a poor choice unless you restrict things greatly. Buses and cars seem to need different interfaces. But, within a narrow range, it might be made to work. If you ask for the &quot;fare&quot; for buses, but not cars then you get in to trouble.</p>
<p>Note that I try to build software, and teach how to build it, so that objects can be responsible for their own actions and when I ask an object to do something it should be able to respond without me knowing (or specifying) its precise implementation.</p>
<p>So, I find problems when the interface and the implementation are too tightly bound together. When I need to do such things. I'd rather extend the interface explicitly (Java, again) and then implement the new interface than simply add public methods to something with a more general interface. Then, (more Java), you can let variables have interface types, rather than concrete types.</p>
<p>FWIW, I can't always accomplish that, but it is a goal and it results in better code.</p>
<p>As I said in a comment to another question, the Linnaeus hierarchy of the animal kingdom consists entirely of abstract &quot;classes&quot; except at the leaves of the structure. I think that is important to keep in mind.</p>

CC BY-SA 4.0
2023-03-27T23:30:23.997Z
2023-03-29T11:15:17.023Z
2023-03-29T11:15:17.023Z
Buffy
<blockquote>
<p>I think that when dealing with new students the principle of inheritance is best explained with analogies to life outside of writing code.</p>
</blockquote>
<p>I'm not so sure. I prefer to use application-centric examples because the connection between the example and an actual program that students care about is clear.</p>
<p>Students are likely never going to write a program dealing with cups, cars or animals or most of the other examples that are typically brought out in courses, leading to a &quot;why should I care?&quot; effect.</p>
<p>I prefer to simply jump right into the actual use case for inheritance. If there is no immediate use case, then I'd try to invent one that motivates a situation where it's awkward not to use inheritance, then show how inheritance solves the problem elegantly. If I can't, then it's probably not useful to teach inheritance at this point (assuming I have control over the curriculum).</p>
<p>For example, if the course deals with back end programming, perhaps a <code>User</code> class with a <code>Moderator</code> subclass which is a <code>User</code> with the ability to delete comments would be a useful motivation. Another <code>User</code> could be <code>UnconfirmedUser</code> which needs email confirmation to become a <code>User</code>. Since just about everyone is familiar with signing up for apps and posting in comment threads (feel free to call the activity &quot;Reddit comments&quot; or similar), the example will immediately connect to an app the students can grasp and realize.</p>
<p>For a course that involves game programming, creating a tree of <code>Entity</code> classes that have <code>Player</code> and <code>Enemy</code> (with further subclasses for different types of enemies) could neatly illustrate avoiding repetition and using polymorphism to loop over the <code>Entities</code> and <code>.render()</code> each one regardless of its type. If you don't have easy access to graphics, this could be part of a text adventure game.</p>
<p>Also in the graphics domain could be a <code>Shape</code> superclass with derived <code>Rectangle</code>, <code>Triangle</code>, <code>Square</code>, etc (with <code>Square</code> being derived from a <code>Rectangle</code>). Most languages have lightweight graphics libraries (often turtle graphics) to enable your students to draw these shapes. Seeing them on the screen is much more concrete than printing out properties of cups or animals.</p>
<p>If you're totally set on &quot;real life&quot; (exists physically) over &quot;real world&quot; (exists in code people actually write), there are still many options that cover both: e-commerce <code>Product</code>s with derived categories, <code>Employee</code> classes with <code>Manager</code>, <code>Intern</code> subclasses (a bit boring and enterprisey), a Minecraft-related inventory system <code>Item</code> or <code>Mineral</code> which maps to physical items, etc.</p>
<p>It's a good instinct to be practical, but keeping one foot firmly in the computer application world keeps the gap bridged and avoids contrivance.</p>

CC BY-SA 4.0
2023-03-31T09:14:33.393Z
His question is basically the same as mine, so maybe you can provide an answer for that one too (thanks in advance!)  https://cseducators.stackexchange.com/questions/6709/some-real-practical-example-to-teach-object-oriented-concepts-and-programming-i
Qiulang 邱朗
CC BY-SA 4.0
2023-03-31T13:25:41.673Z
@Qiulang邱朗 thanks for the response--yes, there are similarities, but I think they're separate questions. Your definition of "real world" is "used in a serious programming project" whereas this poster means "something from everyday life". I think both are potentially problematic so I stick to my answer. Different approaches but same problem--students probably don't care about paths or Python implementation details yet. It's too far away from the sort of fun apps they want to build. If I had to choose, though, I'd take that over the "car/animal"-type examples, although it depends on audience.
ggorlen
CC BY-SA 4.0
2023-03-31T13:26:31.887Z
Also, I've heard that [young people tend not to understand how filesystems work](https://futurism.com/the-byte/gen-z-kids-file-systems), so given the dominance of phones, it's possible that the Python path example will be lost on many students. That can't happen with comments or users which are closer to the user space than the developer space.
ggorlen
CC BY-SA 4.0
2023-05-25T21:43:24.097Z
@ggorlen My statement, "I think that when dealing with new students the principle of inheritance is best explained with analogies to life outside of writing code" was overly opinionated. It might be best to pretend that a student asked, "In something other than python or java-script or code, what real-world thing behaves is sort of like class inheritance?"
Samuel Muldoon
CC BY-SA 4.0
2023-05-25T21:43:30.630Z
@ggorlen when dealing with ***new*** students learning German, if you define German words in terms of other German words, you will be unable to teach much of the German language to the student. Why not teach German by explaining German vocabulary in terms of something outside of the German language. `Haus: ein Ort zum Schlafen, Essen, Baden und zum Aufbewahren von Hab und Gut` If you do not understand any of the words used to define the word **Haus** you won't learn German. Likewise, you cannot learn python from python or java-script from java-script.
Samuel Muldoon
CC BY-SA 4.0
2023-05-25T21:55:49.923Z
@SamuelMuldoon your example isn't a fair comparison, because when you use English to teach German and you describe "haus" in terms of "house", the concept is equally important in both languages and the practicality is obvious. In programming, when you teach OOP with "Cup" and "PlasticCup", those concepts will _never_ appear in an actual app and just serve to create confusion. A better metaphor is trying to teach German with words that are never actually used in German or have no practical value when speaking or writing it.
ggorlen
CC BY-SA 4.0
2023-05-25T21:57:44.937Z
Also, "English to German" and "English to Programming" are apples and oranges. In the former case, both English and German are natural languages, whereas in the second, English is a natural language and programming is a rigid, artificial language used to give instructions to computers, refers to a completely different conceptual world, and has different purpose and syntax. So the benefits of 1:1 translations from English (or general real-world concepts) to programming is not guaranteed. Luckily, "comment threads" are perfectly understandable and real-world, yet have value in computing.
ggorlen
CC BY-SA 4.0
2023-05-25T22:07:50.523Z
If a student insists on a real-world example, I'd ask why they need a real-world example to dig deeper. Maybe they're afraid of embracing programming/computing for what it is. I might try to encourage them to move towards the programmatic concept rather than away from it. But I haven't encountered students for whom inheritance can't be explained by a `Moderator` as a special type of `User` that has most of the same characteristics, plus some additional abilities. If they _really must have physical objects_, I might use blocks and shapes. Apologies for the lengthy reply!
ggorlen
CC BY-SA 4.0
2023-03-27T15:10:17.487Z
2023-03-27T15:10:17.487Z
ggorlen
<p>This isn't as clear cut as your question would have it be. There are several cases where a solution, proposed to be solved by inheritance, could be solved in different ways. For example, your paper/glass cup example is prone to arguments that the material should be a property of the class, not a derivation of the class itself.</p>
<p>Don't do this:</p>
<blockquote>
<p>I need the perfect example so that I can demonstrate all of the inheritance use cases.</p>
</blockquote>
<p>Do this instead:</p>
<blockquote>
<p>I want to showcase this particular behavior. What example would work well to make the behavior seem intuitive?</p>
</blockquote>
<p>Instead of looking for the right example, first consider what you're trying to demonstrate. Usually, this will be a particular behavior (in this case of inheritance). This will help you identify in shaping an example that makes the intended demonstration seem like the most intuitive solution to the problem.</p>
<p>For example, I could focus on polymorphism, specifically the ability to implicitly cast to a base class when passing derived instances into methods. The behavior I'm trying to demonstrate would be something like:</p>
<blockquote>
<p>MethodA only accepts a <code>DerivedA</code>.<br />
MethodB only accepts a <code>DerivedB</code>.<br />
MethodC accepts any kind of <code>Base</code> such as <code>DerivedA</code> or <code>DerivedB</code>.</p>
</blockquote>
<p>To put it plainly: some methods are picky, others are not. I can now think of an example that is very similar to this.</p>
<blockquote>
<p>Carnivores only eat meat.<br />
Herbivores only eat plants.<br />
Omnivores eat any kind of food, such as meat or plants.</p>
</blockquote>
<p>And there you have it, an example that intuitively already matches the kind of behavior that I'm trying to demonstrate.</p>
<pre><code>public class Food {}

public class Meat : Food {}
public class Steak : Meat {}
public class Drumstick : Meat {}

public class Plant : Food {}
public class Grass : Plant {}
public class Leaves : Plant {}

public class Carnivore
{
    public void Eat(Meat meat) {}
}

public class Herbivore
{
    public void Eat(Plant plant) {}
}

public class Omnivore
{
    public void Eat(Food food) {}
}
</code></pre>
<p>And its usage:</p>
<pre><code>var steak = new Steak();
var drumstick = new Drumstick();
var grass = new Grass();
var leaves = new Leaves();

var cat = new Carnivore();
cat.Eat(steak);
cat.Eat(drumstick);
cat.Eat(grass);             // Compiler error - not a Meat!
cat.Eat(leaves);            // Compiler error - not a Meat!

var cow = new Herbivore();
cow.Eat(steak);             // Compiler error - not a Plant!
cow.Eat(drumstick);         // Compiler error - not a Plant!
cow.Eat(grass);             
cow.Eat(leaves);            

var human = new Omnivore();
human.Eat(steak);             
human.Eat(drumstick);         
human.Eat(grass);             
human.Eat(leaves);  
</code></pre>
<p>Is it a perfectly realistic example? No. Not every herbivore eats leaves <em>and</em> grass. Humans don't eat any and all plant products either. But it is the nature of examples that they are simplistic representations. They are simplistic by nature because it makes them easier to digest for students who are being introduced to something new.</p>
<p><strong>To summarize</strong><br />
Tailor your examples to what you're specifically trying to teach. Don't try to pursue the perfect example to be used in all use cases.<br />
By maximizing the relevance of the specific example, you minimize the student's required acceptance of what you're trying to showcase.</p>
<p>Avoid reusing the same examples across multiple behaviors, unless you are absolutely certain that the example is equally intuitive for both cases.</p>

CC BY-SA 4.0
2023-05-10T00:22:18.193Z
2023-05-10T00:22:18.193Z
Flater
<p>When a student is first learning about class inheritance it is nice to use an example from every-day life. For example, <code>Plastic Cups</code> are <code>Cups</code> and <code>GlassCups</code> are also <code>Cups</code>.</p>
<pre class="lang-python prettyprint-override"><code>class Cup:   
    pass

class PlasticCup(Cup):
    pass  

class PaperCup(Cup):
    pass  

class RoughHewnWoodenCup(Cup):
    pass  

class Glass(Cup):
    pass  
</code></pre>
<p>I am aware that interface classes exist, wrapper classes exist, etc...</p>
<p>I think that when dealing with new students the principle of inheritance is best explained with analogies to life outside of writing code.</p>
<p>For example, <code>PlasticCups</code> are <code>Cups</code>, so <code>PlasticCups</code> inherit from the <code>Cup</code> class.</p>
<p>I have an example using Cups but my questions is,</p>
<blockquote>
<p>What Examples of class inhertance can you provide which do not talk about drinking vessels for beverages such as water or fruit juice?</p>
</blockquote>
<p>Your answer need not use python-style syntax. Use whatever syntax you prefer.</p>

CC BY-SA 4.0
2023-03-31T09:09:02.700Z
I alway use **path**, as I asked here https://cseducators.stackexchange.com/questions/6709/some-real-practical-example-to-teach-object-oriented-concepts-and-programming-i
Qiulang 邱朗
<object-oriented-paradigm><code-example><objects-first>
What is an example of class inheritance in every-day life which is easy to write in an object-oriented language?
# What is an example of class inheritance in every-day life which is easy to write in an object-oriented language?

(Asked by: username_0 on 2023-03-27)

When a student is first learning about class inheritance it is nice to use an example from every-day life. For example, Plastic Cups are Cups and GlassCups are also Cups.
class Cup:   
    pass

class PlasticCup(Cup):
    pass  

class PaperCup(Cup):
    pass  

class RoughHewnWoodenCup(Cup):
    pass  

class Glass(Cup):
    pass  

I am aware that interface classes exist, wrapper classes exist, etc...
I think that when dealing with new students the principle of inheritance is best explained with analogies to life outside of writing code.
For example, PlasticCups are Cups, so PlasticCups inherit from the Cup class.
I have an example using Cups but my questions is,

What Examples of class inhertance can you provide which do not talk about drinking vessels for beverages such as water or fruit juice?

Your answer need not use python-style syntax. Use whatever syntax you prefer.

**Tags:** object-oriented-paradigm, code-example, objects-first

> **Comments:**
> **username_1**: I alway use **path**, as I asked here https://cseducators.stackexchange.com/questions/6709/some-real-practical-example-to-teach-object-oriented-concepts-and-programming-i  

---

## 5 answers

### Answer by username_5 on 2023-03-27. Score: 8

> I think that when dealing with new students the principle of inheritance is best explained with analogies to life outside of writing code.

I'm not so sure. I prefer to use application-centric examples because the connection between the example and an actual program that students care about is clear.

Students are likely never going to write a program dealing with cups, cars or animals or most of the other examples that are typically brought out in courses, leading to a "why should I care?" effect.

I prefer to simply jump right into the actual use case for inheritance. If there is no immediate use case, then I'd try to invent one that motivates a situation where it's awkward not to use inheritance, then show how inheritance solves the problem elegantly. If I can't, then it's probably not useful to teach inheritance at this point (assuming I have control over the curriculum).

For example, if the course deals with back end programming, perhaps a `User` class with a `Moderator` subclass which is a `User` with the ability to delete comments would be a useful motivation. Another `User` could be `UnconfirmedUser` which needs email confirmation to become a `User`. Since just about everyone is familiar with signing up for apps and posting in comment threads (feel free to call the activity "Reddit comments" or similar), the example will immediately connect to an app the students can grasp and realize.

For a course that involves game programming, creating a tree of `Entity` classes that have `Player` and `Enemy` (with further subclasses for different types of enemies) could neatly illustrate avoiding repetition and using polymorphism to loop over the `Entities` and `.render()` each one regardless of its type. If you don't have easy access to graphics, this could be part of a text adventure game.

Also in the graphics domain could be a `Shape` superclass with derived `Rectangle`, `Triangle`, `Square`, etc (with `Square` being derived from a `Rectangle`). Most languages have lightweight graphics libraries (often turtle graphics) to enable your students to draw these shapes. Seeing them on the screen is much more concrete than printing out properties of cups or animals.

If you're totally set on "real life" (exists physically) over "real world" (exists in code people actually write), there are still many options that cover both: e-commerce `Product`s with derived categories, `Employee` classes with `Manager`, `Intern` subclasses (a bit boring and enterprisey), a Minecraft-related inventory system `Item` or `Mineral` which maps to physical items, etc.

It's a good instinct to be practical, but keeping one foot firmly in the computer application world keeps the gap bridged and avoids contrivance.

> **Comments:**
> **username_1**: His question is basically the same as mine, so maybe you can provide an answer for that one too (thanks in advance!)  https://cseducators.stackexchange.com/questions/6709/some-real-practical-example-to-teach-object-oriented-concepts-and-programming-i  
> **username_5**: @Qiulang邱朗 thanks for the response--yes, there are similarities, but I think they're separate questions. Your definition of "real world" is "used in a serious programming project" whereas this poster means "something from everyday life". I think both are potentially problematic so I stick to my answer. Different approaches but same problem--students probably don't care about paths or Python implementation details yet. It's too far away from the sort of fun apps they want to build. If I had to choose, though, I'd take that over the "car/animal"-type examples, although it depends on audience.  
> **username_5**: Also, I've heard that [young people tend not to understand how filesystems work](https://futurism.com/the-byte/gen-z-kids-file-systems), so given the dominance of phones, it's possible that the Python path example will be lost on many students. That can't happen with comments or users which are closer to the user space than the developer space.  
> **username_0**: @username_5 My statement, "I think that when dealing with new students the principle of inheritance is best explained with analogies to life outside of writing code" was overly opinionated. It might be best to pretend that a student asked, "In something other than python or java-script or code, what real-world thing behaves is sort of like class inheritance?"  
> **username_0**: @username_5 when dealing with ***new*** students learning German, if you define German words in terms of other German words, you will be unable to teach much of the German language to the student. Why not teach German by explaining German vocabulary in terms of something outside of the German language. `Haus: ein Ort zum Schlafen, Essen, Baden und zum Aufbewahren von Hab und Gut` If you do not understand any of the words used to define the word **Haus** you won't learn German. Likewise, you cannot learn python from python or java-script from java-script.  
> **username_5**: @SamuelMuldoon your example isn't a fair comparison, because when you use English to teach German and you describe "haus" in terms of "house", the concept is equally important in both languages and the practicality is obvious. In programming, when you teach OOP with "Cup" and "PlasticCup", those concepts will _never_ appear in an actual app and just serve to create confusion. A better metaphor is trying to teach German with words that are never actually used in German or have no practical value when speaking or writing it.  
> **username_5**: Also, "English to German" and "English to Programming" are apples and oranges. In the former case, both English and German are natural languages, whereas in the second, English is a natural language and programming is a rigid, artificial language used to give instructions to computers, refers to a completely different conceptual world, and has different purpose and syntax. So the benefits of 1:1 translations from English (or general real-world concepts) to programming is not guaranteed. Luckily, "comment threads" are perfectly understandable and real-world, yet have value in computing.  
> **username_5**: If a student insists on a real-world example, I'd ask why they need a real-world example to dig deeper. Maybe they're afraid of embracing programming/computing for what it is. I might try to encourage them to move towards the programmatic concept rather than away from it. But I haven't encountered students for whom inheritance can't be explained by a `Moderator` as a special type of `User` that has most of the same characteristics, plus some additional abilities. If they _really must have physical objects_, I might use blocks and shapes. Apologies for the lengthy reply!  

---

### Answer by username_6 on 2023-05-10. Score: 4

This isn't as clear cut as your question would have it be. There are several cases where a solution, proposed to be solved by inheritance, could be solved in different ways. For example, your paper/glass cup example is prone to arguments that the material should be a property of the class, not a derivation of the class itself.
Don't do this:

I need the perfect example so that I can demonstrate all of the inheritance use cases.

Do this instead:

I want to showcase this particular behavior. What example would work well to make the behavior seem intuitive?

Instead of looking for the right example, first consider what you're trying to demonstrate. Usually, this will be a particular behavior (in this case of inheritance). This will help you identify in shaping an example that makes the intended demonstration seem like the most intuitive solution to the problem.
For example, I could focus on polymorphism, specifically the ability to implicitly cast to a base class when passing derived instances into methods. The behavior I'm trying to demonstrate would be something like:

MethodA only accepts a DerivedA.
MethodB only accepts a DerivedB.
MethodC accepts any kind of Base such as DerivedA or DerivedB.

To put it plainly: some methods are picky, others are not. I can now think of an example that is very similar to this.

Carnivores only eat meat.
Herbivores only eat plants.
Omnivores eat any kind of food, such as meat or plants.

And there you have it, an example that intuitively already matches the kind of behavior that I'm trying to demonstrate.
public class Food {}

public class Meat : Food {}
public class Steak : Meat {}
public class Drumstick : Meat {}

public class Plant : Food {}
public class Grass : Plant {}
public class Leaves : Plant {}

public class Carnivore
{
    public void Eat(Meat meat) {}
}

public class Herbivore
{
    public void Eat(Plant plant) {}
}

public class Omnivore
{
    public void Eat(Food food) {}
}

And its usage:
var steak = new Steak();
var drumstick = new Drumstick();
var grass = new Grass();
var leaves = new Leaves();

var cat = new Carnivore();
cat.Eat(steak);
cat.Eat(drumstick);
cat.Eat(grass);             // Compiler error - not a Meat!
cat.Eat(leaves);            // Compiler error - not a Meat!

var cow = new Herbivore();
cow.Eat(steak);             // Compiler error - not a Plant!
cow.Eat(drumstick);         // Compiler error - not a Plant!
cow.Eat(grass);             
cow.Eat(leaves);            

var human = new Omnivore();
human.Eat(steak);             
human.Eat(drumstick);         
human.Eat(grass);             
human.Eat(leaves);  

Is it a perfectly realistic example? No. Not every herbivore eats leaves and grass. Humans don't eat any and all plant products either. But it is the nature of examples that they are simplistic representations. They are simplistic by nature because it makes them easier to digest for students who are being introduced to something new.
To summarize
Tailor your examples to what you're specifically trying to teach. Don't try to pursue the perfect example to be used in all use cases.
By maximizing the relevance of the specific example, you minimize the student's required acceptance of what you're trying to showcase.
Avoid reusing the same examples across multiple behaviors, unless you are absolutely certain that the example is equally intuitive for both cases.


---

### Answer by username_2 on 2023-03-27. Score: 2

It depends on the goal. For an initial, highly intuitive brush, I've frequently used animals. They share some advantages over cups.

1. There are a *lot* of them.
2. They already come pre-categorized into class trees thanks to hundreds of years of labor by thousands of people.
3. It's not just a good example, it is quite real. Animals utilize genuine inheritance. Racoons are able to produce bile for the same reason that we are, because we inherited the DNA for a gallbladder from our common ancestors, and the behaviors of these organs is essentially the same for both species.1
4. Animals don't just do well to explain inheritance, but lend themselves towards a lot more advanced thinking.

They clearly lend themselves to inheritance well, because they are genuine manifestations of it in nature. (All mammals growHair(), but along the tree, rodentia's approach would implement that as fur, and the naked mole rat would have to override that yet again.)

***At this point it's worth noting that I do not advocate sticking to only this example. Once it has been made intuitive, it's time to move on and have students try it in other contexts.***

The example also readily (happily!) switches over to teaching abstract classes once students are ready. *(Earlier we examined a fictional animal system. But there was a bit of a problem before that we didn't delve into. Let's look at this now: I can instantiate a* ***poecilia latipina,*** *but what would it mean to instantiate a fish?? That shouldn't be possible! "Fish" isn't a specific fish, it's an abstract idea of fish...)*

It also lends itself to interfaces. *(Earlier, we looked at a fictional animal inheritance system. It had another problem! We might start with the idea that birds fly, but what of penguins? Or bats? We need a new tool for this action.)*

If you want them to think deeply about OOP (*after* they've learned the pieces of it well) have them consider [carcinization](https://en.m.wikipedia.org/wiki/Carcinisation). How would something like that be represented in OOP? To my taste, there is no fixed answer, but it's an interesting question and lends itself to deeper thinking about both OOP and biology.

#Bad Coding Practice in the Animal Kingdom#

There was an objection in the comments section, pointing out that it is bad practice to have a child's interface become larger than the parent interface. I would strenuously argue that, while this is true, we are still duty-bound to explain what inheritance can do, and in languages like Java and C++, we are able to expand the interface. We must make the mechanics of this as intuitive as the rest.

It's also worth noting that all of this animal stuff probably takes no more than 15 (cumulative!) minutes over three different days. I also heavily lean into good coding practice in my courses, but I do it in many passes.

This is an example from nature. It does not follow good coding style, but that's not necessarily a flaw. It is perfectly reasonable to revisit the animal example later on and talk about why we might not want to allow children to expand interfaces in our own programming projects.

1 You may notice an apparent difference between biological and OOP inheritance in that due to limited lifespan, we are not literally handing our bilirubin to our ancestor in order to make the bile - we instead inherit the mechanism to do it ourselves. However, I would argue that this is worth mentioning, but not a difference that you would want to lean into too hard in the classroom, as this passing of information up and down the hierarchy breaks OOP's metaphor. We are not meant to even be aware of such cross-generational passing when we use an object in OOP. It is only important briefly when coding the object itself.

> **Comments:**
> **username_2**: **Comments have been [moved to chat](https://chat.stackexchange.com/rooms/144945/discussion-on-answer-by-ben-i-what-is-an-example-of-class-inheritance-in-every); please do not continue the discussion here.** Before posting a comment below this one, please review the [purposes of comments](/help/privileges/comment). Comments that do not request clarification or suggest improvements usually belong as an [answer](/help/how-to-answer), on [meta], or in [chat]. Comments continuing discussion may be removed.  

---

### Answer by username_3 on 2023-03-29. Score: 0

Real world examples are good, before you get to coding. Use them first to explain the idea. Then introduce a coding problem: How can we use this idea to simplify this code.

Some languages prevent the most powerful use of this idea. E.g Java only allows multiple inheritance of interfaces. Eiffel, Python (it's a duck), and Rust, don't have this problem.

> **Comments:**
> **username_0**: I am aware that python uses duck typing, but I am confused why you wrote something like, "Python (it is a duck)". The Python programming language uses duck typing, but python itself is not a duck-type. An example of duck typing would be a class object which emulates the `list` class by defining all of the following attributes: `append`, `clear`,  `copy`, `count`,  `extend`, `index`, `insert`, `pop`, `remove`, `reverse`, `sort`  
> **username_3**: @SamuelMuldoon I did not mean to be that literal.  
> **username_0**: I agree that real-world examples are useful before students get into writing syntactically worry code in order to explain the idea of inheritance. The question is, what is a specific example of a real-world example? Maybe `souring powder` and `light-bulbs` inherit from inedible items? I am not sure that is an example students would find interesting.  
> **username_3**: @SamuelMuldoon python can quack, so it is a duck (according to duck-typing).  
> **username_3**: @SamuelMuldoon a class does not implement the set of things that are not in another set. E.g. you can't make a class `not edible`. You could, but what methods would it have? `don't eat`?  
> **username_3**: `souring powder` is that `saw dust`, the dust that comes from sawing wood. That is `edible`, they put it on some `edible` products. What it is not is `food`.  

---

### Answer by username_4 on 2023-03-27. Score: 0

This is a harder question than it seems if you want to get across the idea that a type hierarchy should contain variations but with the *same interface*. If the interface gets extended as you go down the hierarchy then you have the problem that you too-often need to do type casting of variables (Java) or risk runtime failure (Python) if you make certain assignments and then try to message the referenced object.

In particular, I try to get this idea across early, since if it isn't taught and the opposite process is, it can be very hard to unlearn bad (IMO) habits and replace them. It was for me in fact.

It is the same problem you get using too many if-statements and the program becomes so ad-hoc that it is difficult to understand, much less modify.

Your example of cups is pretty good, I think, since cups should all be able to have the same usages (think UI). So, I'd try to think about things in real life that are basically alike, but have variations.

Clothing fits that in some ways. There are many variations on "skirt" or "pants" or "jacket" that all interface to the world in the same way. They have color, closure methods, sizes, etc. but a visit to a clothing store will give you a sense of the variations.

I'll also note that all of the keys on my current keyboard have the same "interface" but all perform a different task.

Smartphones are pretty generic, actually, in spite of the marketing hype. Mine is probably a lot like yours.

Vehicle is a poor choice unless you restrict things greatly. Buses and cars seem to need different interfaces. But, within a narrow range, it might be made to work. If you ask for the "fare" for buses, but not cars then you get in to trouble.

Note that I try to build software, and teach how to build it, so that objects can be responsible for their own actions and when I ask an object to do something it should be able to respond without me knowing (or specifying) its precise implementation.

So, I find problems when the interface and the implementation are too tightly bound together. When I need to do such things. I'd rather extend the interface explicitly (Java, again) and then implement the new interface than simply add public methods to something with a more general interface. Then, (more Java), you can let variables have interface types, rather than concrete types.

FWIW, I can't always accomplish that, but it is a goal and it results in better code.

As I said in a comment to another question, the Linnaeus hierarchy of the animal kingdom consists entirely of abstract "classes" except at the leaves of the structure. I think that is important to keep in mind.


---

