Live data from Hacker News

If Inheritance is so bad, why does everyone use it?

buttondown.email

41–50 of 389 posts

Re: If Inheritance is so bad, why does everyone use it?

#41

Here is my take on it. At one point "Object Oriented" became "Blockchain" (or now Gen AI) of those times. You had to be "object oriented" in order to be taken seriously. This applied to everything. Even finished software products were called "built using object oriented". The esoteric concept of inheritance became popular after that. At some point it became so popular that people figured out that it is not really a g…

Also a semi religion, I'm always seeing people say before OOP everything was terrible, and everything good thing is due to OOP (eg structs, methods, polymorphism)

Re: If Inheritance is so bad, why does everyone use it?

#42
Inheritance is not so bad for native UI stuff where it makes sense for the class libraries.

But in work code I don’t see it much. If it is used it is light weight. Often used incorrectly for splitting code into different files rather than actual inheritance (giveaway is one one derived class!)

Re: If Inheritance is so bad, why does everyone use it?

#43

I don't think inheritance is bad at all. It is very often the easiest way by far to model a problem. Sure, it's not perfect, but I think it is wildly overhated by a vocal minority.

Depends on how you use it, but in Java I prefer to use interfaces and no subclassing. I find classes with abstract methods hard to reason about, and much prefer to leverage Functions/lambdas where possible.

Re: If Inheritance is so bad, why does everyone use it?

#44
post #27

I work on a very large codebase. We use inheritance and composition. I totally agree that inheritance should be used carefully. However, there are times when composition requires a lot more code and downstream maintenance. Let's stay I have a base class A. Let's say I have 70 classes that inherit from A. These classes must serialize/deserialize from disk. My choice here is that I can add a new data member to A and th…

> Let's stay I have a base class A. Let's say I have 70 classes that inherit from A. The alternative case is that you have 70 classes that CONTAIN A. You still only have to change A.

[dead]

Re: If Inheritance is so bad, why does everyone use it?

#46
I only tend to see inheritance in engines and libraries, where it makes sense to create more generic, reusable and composable code, since most of the functionality in these is defined by technical people.

It makes no sense to use inheritance in the business layer, because a single feature request can make a lot of the carefully crafted abstractions obsolete.

Re: If Inheritance is so bad, why does everyone use it?

#47
post #27

I work on a very large codebase. We use inheritance and composition. I totally agree that inheritance should be used carefully. However, there are times when composition requires a lot more code and downstream maintenance. Let's stay I have a base class A. Let's say I have 70 classes that inherit from A. These classes must serialize/deserialize from disk. My choice here is that I can add a new data member to A and th…

> Let's stay I have a base class A. Let's say I have 70 classes that inherit from A. The alternative case is that you have 70 classes that CONTAIN A. You still only have to change A.

Yes, but in my example, in the 70 classes, all the ::Read and ::Write methods must still say:

    a.Read( ... )
    a.Write( ... )
And depending on the use case and design, they also need methods such as:

   A& GetA() { return a; );
   const A& GetA() const { return a; }

Re: If Inheritance is so bad, why does everyone use it?

#48

I don't think inheritance is bad at all. It is very often the easiest way by far to model a problem. Sure, it's not perfect, but I think it is wildly overhated by a vocal minority.

Have you ever seen wildly over-architected OO code where everything seems to be an abstract class and it seems impossible to find out where stuff actually happens?

Inheritance is like a lot specialised tools - it can be useful in some situations but I think those are rarer than supporters might thing. Completely refusing to use inheritance and always using inheritance both seem like extreme views that should be avoided.

Re: If Inheritance is so bad, why does everyone use it?

#49
My impression is the opposite, especially from when I used to work as a full-time Java dev. I often asked myself:

Is there a place outside of GUI programming where inheritance is used in non-habitual and useful way? I can't think of many.

More often than not you have a final class that you are supposed to use and the petrified hierarchy above that is of not much use.

Re: If Inheritance is so bad, why does everyone use it?

#50
post #26

OOP is easy to understand and explain and it makes sense initially, plus a lot of people specialize in languages/frameworks that enforce it, so it becomes easy to get trapped in the OOP world. It also usually comes with DDD (which is a solution to a problem you shouldn't have had in the first place) which is a way to limit the damages of OOP into contextual areas. I also think the blanket statement (OOP is bad) does…

I disagree. Starting with separating class and object have never been helpful when I've tried to teach computer programming, while functions seems to have been more intuitive to those people. After a while you get to closures, which are pretty much objects without classes, and then factory functions that produce closures and there you have something like a class as well. If I were to design a course I'd probably foll…

But you go from the bottom up here, I don't like to describe it that way.

I prefer to say that we naturally classify objects around us using fuzzy boundaries like "a house", "a cat", which don't exactly mean anything: they are templates we use later to actually generate an actual house, or an actual cat (on a piece of paper as a drawing for instance).

The world being separated between our internal classes and the interactive instances of them, we can code that way too: we look for what we actually need in a concept, name it and define only what we need, then instantiate several concrete actors interacting together. Each actor is complete, well defined, with contracts for interactions.

You can then start building on top of this more complex systems, talking in English and defining rationally the world of your little model.

If you start talking about functions, you're basically aliasing a memory address for a bunch of code: you'll goto that function address, with some parameters at some other address, do a bunch of things and put the result in another address for the next function to process. You're building at best a suite of pipelines, which ends up being a little bit too technical and static for my taste.

Another way to defend modelling a software with classes and object, in my view, without trying to talk about functions, is the blank page effect: imagine arriving at random at some assignment. You understand vaguely the business problem, now you need to code a solution. You have 6 months, will generate a few millions a year and will require a team of 10 people eventually to test, maintain, operate and debug: you start with defining functions generating functions with callback parameters in Python, or you launch IntelliJ and you do a Java class model ? I'd be terrified modelling complex problems with just functional pipelines, I think it's just way more obvious to talk about objects at all time if you're gonna do something that is not just processing inputs into well defined outputs.

Post reply on HN