logoalt Hacker News

taylodl01/23/20251 replyview on HN

That's an interesting perspective on inheritance.

The problem I see inheritance solving is not having to distribute subtype-specific logic throughout your code base - functions can interact with objects in a generic manner and you get to keep subtype-specific code all in one spot. That's a win.

Inheritance isn't the only means for achieving this capability, though. You can also use interfaces and protocols. I prefer to use interfaces. If my class needs to implement an interface than that's explicit: it implements the interface. I can use inheritance if the class really IS-A variant of another class and it can use that base class in fulfilling its obligation in implementing that interface. That's an implementation detail. But the fact it has responsibility for implementing that interface is made explicit.


Replies

sirwhinesalot01/24/2025

Yeah but that's what I mean by using it as a tool, you're not trying to model some weird taxonomy with your classes (like the square/rectangle situation), you're using a language feature to enable generic code and/or for code reuse, any real-world relationship between the concepts is irrelevant.

Inheritance is bad because it enforces a subtyping relationship alongside code reuse and data reuse. It is extremely rare you want all 3 together and even when you think you do there's a rude awakening coming your way, specially if you did the "model real world concepts as a class hierarchy thing."

The object-relational mismatch is a weakness of the object side, not of the relational. Use the right tool for the job and forget about stupid programming paradigms.