Inheritance is one of those object-oriented concepts that creates a lot of conflicts. You’ll hear people debating what constitutes an “is-a” versus a “has-a” relationship, you’ll hear “favor composition over inheritance”, you’ll see languages adopt mix-in patterns which use inheritance to do composition. Used well, the feature can make your code cleaner to read and easier to maintain. Used poorly, it’s a way to get your polymorphism with a side of spaghetti code.
Greg was working on a medical data application’s front end. This representative line shows how they use inheritance:
public class Patient extends JavascriptStringBuilder
Greg writes: “Unfortunately, the designers were quite unacquainted with newfangled ideas like separating model objects from the UI layer, so they gave us this gem.”
This, of course, was a common pattern in the application’s front end. Many data objects inherited from string builder. Not all of them, which only helped to add to the confusion.
As for why? Well, it gave these objects a “string” function, which they could override to generate output. You want to print a patient to the screen? What could be easier than calling patient.string()?
Remy Porter
Source link
