I claim that Real Metaphors Are Promiscuously Mixedđ“…®, which is not a property of metaphorical program names like `Invoice` or `Car`. But what about subclasses?
content
A classic example when teaching object-oriented programming is to have a more-abstract class named `Vehicle` and a more-concrete class named `Car`. I concede that “it’s a vehicle or is it a car?” has some of the same… texture as “it’s a Building or is it a Journey?” Just as a Building can add new associations to an argument thought of as a Container, a `Car` class adds new properties, methods, or associations to a `Vehicle` class. However, the way subclasses are *generally* used differs. If you think of code as the way we talk to the computer – and other programmers – we’re usually talking about *either* the superclass (`Vehicle`) or the subclass (`Car`), not both at the same time. Consider a Java method that takes an argument of type `Vehicle`. The whole *point* of declaring it so is that we’re not supposed to use anything specific to `Car` in that code. Indeed, doing so with a runtime check is generally considered a design smell. Similarly, if we’re taking an argument declared to be of type `Car`, we’re generally indifferent to whether a method we’re using is defined up in `Vehicle` or in the `Car` subclass. That is, we not in a situation equivalent to realizing, “Hey! This car is a `Vehicle`, so I will think of it in a different way that gives me a bunch of new abilities.” That can only be true if something about Cars falsifies a true fact about Vehicles. It’s generally considered dodgy to do that in programming. But it’s doing that with pairs of conceptual metaphors that gives those metaphors their *oomph* for reasoning.
objections
Inheritance of Implementation might be a better example than "proper" inheritance.