> A little OT...but does anyone have insight into the historical reasons of why inheritance seems to be the default entry point into teaching/explaining OOP and

> A little OT...but does anyone have insight into the historical reasons of why inheritance seems to be the default entry point into teaching/explaining OOP and classes? Meyer's OOSC doesn't. It explains inheritance 1/3 through the book, after generics (parametric polymorphism) and Design by Contract. Incidentally, OOSC has this paragraph about inheritance that is worth remembering: "Neither the Open-Closed principle nor redefinition in inheritance is a way to address design flaws, let alone bugs. If there is something wrong with a module, you should fix it — not leave the original as it is and try to correct the problem in a derived module. (The only potential exception to this rule is the case of flawed software which you are not at liberty to modify.) The Open-Closed principle and associated techniques are intended for the adaptation of healthy modules: modules that, although they may not suffice for some new uses, meet their own well-defined requirements, to the satisfaction of their own clients." (Emphasis in the original.) The Item class is not an example of a healthy module. It has been written in an ad-hoc fashion, without concerns about its requirements or thoughts about what contracts it should offer to its clients (i.e. how it interacts with other modules). Unsurprisingly, adapting it through inheritance results in breakage.