Live data from Hacker News

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

buttondown.email

221–230 of 389 posts

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

#221

Earlier quoted context omitted.

>It looks like composition over inheritance has caught on as the better default in other languages, but in the CSS world people still cling to the cascade as a best practice for some reason I find this falls into generally two camps, those who want to fight the browser and those who don’t. Those that tend to hate the cascade tend to fight the browser a lot, whether they realize it or not. Generally speaking, they wan…

> Those that tend to hate the cascade tend to fight the browser a lot, whether they realize it or not. Generally speaking, they want things to work a certain way (IE everything in isolation) and prefer to think of styles isolated bits. So, wouldn't that be the browser fighting them, then? They want something specific, and the broswer forces a paradigm upon them that they don't want. They are the humans and the browse…

If someone picks up a hammer and struggles to pound screws in with them, it’s not the hammer that’s defective.

I don’t think CSS is the perfect tool for all browser-based styling but it’s the tool that’s there and it’ll probably work a lot better if you use it the way it’s intended to be used. If you want a screwdriver instead of a hammer… you have options (don’t target a browser, propose an alternative to CSS, use something that compiles down to CSS).

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

#222

The key is "prefer composition to inheritance" and dates back to Gang of Four. The word "prefer" is critical to understand. It just means "usually choose A over B" not "B is never the right answer." Unfortunately, since we - as an industry - like hard and fast rules, we move towards that second explanation and act like inheritance never makes sense. Like any tool, there's a time and place where it is the best tool, o…

I agree with this sentiment but I also must say that the time's I've needed inheritance have been few and far between. I have seen really good examples where it works really well (UX is pretty common, but I've also seen really clean cases like data structures with complex interfaces and a simple abstract class). Where I think inheritance works best is when the state in base classes is limited and the interface is qui…

> Where I think inheritance works best is when the state in base classes is limited and the interface is quiet clear. Ideally where you are meant to override is also well defined.

What benefit is inheritance providing here? What you described sounds mostly like a struct, at which point the only value the interface provides is possibly some computed fields.

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

#223

Nobody calls it this, but cascading styles in CSS is just like inheritance and I think should be avoided for all the same reasons. I feel it's a big part of why CSS at scale becomes unmaintainable. There isn't even a built-in way to compose two classes together if you want to avoid cascading/inheritance. It looks like composition over inheritance has caught on as the better default in other languages, but in the CSS…

>It looks like composition over inheritance has caught on as the better default in other languages, but in the CSS world people still cling to the cascade as a best practice for some reason I find this falls into generally two camps, those who want to fight the browser and those who don’t. Those that tend to hate the cascade tend to fight the browser a lot, whether they realize it or not. Generally speaking, they wan…

I'd ask what you mean by "fighting the browser"- as generally, the number one way to ruin the performance of your CSS is to introduce depth to it. In general, keeping everything isolated regularly leads to better rendering performance.

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

#224

It's not bad. People like to feel smug by saying OO is bad and hence inheritance, meanwhile using some construct in their FP that is really the same thing.

you seem to be misunderstanding different terms. You can do OO without inhertitence. inheritance is the worst as you grip with you types. just use strategy patterns instead.

[deleted]

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

#225

I feel people don't understand what inheritance and (object orientation in general) is useful for, misuse it, and then it gets a bad reputation. It's not about making nice hierarchies of Cars, Fruits, and Ovals. For me the main point is (runtime) polymorphism. E.g. you have a function that takes a general type, and you can pass multiple specific types and it will do the right thing. And if you want to avoid huge if-e…

If people get it wrong so regularly, what value is it providing as a concept? These concepts are supposed to help us reach something better, if you have to add 30 caveats to every part of it, all it did was hide its own complexity from you, instead of managing it for you.

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

#226
post #93

Earlier quoted context omitted.

Most of us have no contact with Java. But Java offers little else than inheritance to use to organize a system, so Java coders use it for everything. They are not exactly wrong, except in using Java at all. But sometimes is all that is allowed.

java offers composition, like pretty much all programming languages if you have a person class and you have students and teachers the correct thing to to is NOT to make student and teacher inherit from person it's to make student and teacher have a person attribute + the other attributes that constitute a student and teacher respectively

By "correct" here you only mean fashionable. Either approach works. Each has its merits and its costs.

Any big enough system will have parts that are most sensibly built object-oriented, and other parts that are more reasonably functional, plus anything else you can think of.

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

#227
Inheritance is really just a public interface, a private interface and automatic delegation of those interfaces to the base class.

The problems with inheritance are:

- people shove code in the base class to dedup it without thinking about design

- people add public and protected methods without thinking about interface design

- the names of the base class and the public and protected interfaces are exactly the same thing

The last point is that if you have a FooBase class which is public then you can wind up with a bunch of List containers that are coupled to the base class and external methods that take FooBase parameters along with a bunch of concrete instances which are dependent upon the FooBase class protected interface and code implementation. This creates the brittle base class problem.

If instead you had an IFoo interface and only ever used List instead of FooBase anywhere then you could always define FooBasev2 which implemented IFoo as well and FooBase and FooBasev2 can coexist in your codebase without having to break any external consumers (open-closed principle in practice).

If base classes were only allowed to be used in inheritance and couldn't be parameters, generics, etc then that would force users to create base classes and public interfaces in pairs and would decouple their names and by writing the public interface down as its own thing developers would be more likely to focus on that design.

And really inheritance is just syntax sugar around having a component (the base class) which has automatic delegation of of the public interface and protected interface to it in the inheriting object, with so little typing that it becomes easy to not think about what you're doing -- and while reusing the same name for three different things and creating tight coupling, and you can't dependency inject different baseclasses at runtime. If languages had better terse syntax for delegation then composition would get a lot easier to use like inheritance is (which is something that Go oddly enough gets more-or-less correct, dunno why they didn't mandate piles of boilerplate for delegation like they did for error checking).

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

#228
post #111

Earlier quoted context omitted.

Doing every simple thing that used to be done in "normal procedural" way in functional paradigm instead when using something like Scala or fp-ts in TypeScript. Causing engineers to completely change their mental model of how the code runs, which I still have intuitive trouble imagining correctly and I see it with other developers as well. A lot of energy goes into trying to understand how to do a simple action. It is…

lol it's the opposite? map, flatmap, fold etc are very clearly defined operations with very clear use cases and rules. loops are not, you can do whatever you want (often mutating the underlying, rug pulling you every iteration) not being familiar with fp doesn't mean it's objectively worse

[deleted]

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

#230

I feel people don't understand what inheritance and (object orientation in general) is useful for, misuse it, and then it gets a bad reputation. It's not about making nice hierarchies of Cars, Fruits, and Ovals. For me the main point is (runtime) polymorphism. E.g. you have a function that takes a general type, and you can pass multiple specific types and it will do the right thing. And if you want to avoid huge if-e…

Except inheritance is the premature optimisation of interfaces. Inheritance forces you to define the world in terms of strict tree hierarchies, which is very easy to get wrong. You may even do a great job today, but tomorrow such properties don't hold anymore. Regular composition allows the same functionality without making such strong assumptions on the data you are modelling.

> Inheritance forces you to define the world in terms of strict tree hierarchies,

No, it doesn’t.

Inheritance is the outcome of deciding to model some part of the problem space with a tree hierarchy (that potentially intersects other such heirarchies). It doesn’t force you to do anything.

I suppose if there was a methodology which forced you, as the only modeling method, to exclusively use single inheritance, that would force you to do what you describe, but…that’s not inheritance, that’s a bunch of weird things layered on top of it.

Post reply on HN