You're confusing inheritance with implementing an interface. I'm not sure there is an example in the real world, because the real world is concerned with function, not taxonomy. It hardly makes sense to say "cordless drill inherits from screw driver"; rather, they both implement the "drives screw" interface. Ontological inheritance really doesn't make any sense at all for modeling systems (sometimes ontologies are useful as data in a system, but probably never for modeling the system itself).
They wanted an example of inheritance. Something like:
You need an office. You could create a new office from scratch, or you could also just put a desk in a room in your house and give it a unique address like "Suite 1". Now it's both a Room and a HomeOffice.
But if your HomeOffice exposes a method BuildWall(), which mutates the office into a collection of two Rooms, then it would stop fitting the definition of a Room after calling that method.
I don't know if there are different tax consequences for one-room vs. multi-room home offices, but that's one area where the distinction could at least conceivably be significant enough to affect whether you'd prefer to build a separate office or inherit the old room, or maybe just rent an existing office from a third party.
Oh rats, my mistake. It is harder to come up with s good example of mechanical inheritance. Something like the cassette tape adapter kinda feels like inheritance, in the sense that it can be substituted in for a normal cassette tape but provides its own unique functionality.
Yes, I'm struggling to think of a good mechanical example of inheritance as code reuse.
But I don't agree with the "that's an interface, not inheritance" argument. Well designed super classes tend to provide an interface - they just don't use the "interface" keyword.
If you declare a method as abstract, you're defining an interface that subclasses use to define new behaviour. You see this all the time. If a method is defined as protected, you're saying "I'm allowing subclasses to use this interface to change behaviour".
For example, test frameworks usually provide an overridable method that's run before each test - setUp. That's interface - "I will call setUp before every test - feel free to override it".
To me, that's where shit gets hard. It has to have a well defined interface, it has to be an is-a relationship and it has to be a subtype (Liskov). That's why we see composition over inheritance because it's far simpler to just drop one of the constraints and get decent work done.
