Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

buttondown.email

Post reply on HN
Print view View original

361–370 of 389 posts

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

#361

Post by UncleMeat »

bluetomcat wrote: post #69
captainmuon wrote: post #39

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…

Polymorphism is doable in plain old C with lookup tables and function pointers. If that is the only benefit, what is the point of creating a language where everything is an object?

Control flow is doable with gotos. What benefit therefore is structured programming?

Dynamic dispatch is implemented under the hood with lookup tables and function pointers. Sometimes, it is nice for a language to wrap a fiddly thing in a more abstract structure to make it easier to read, understand, and write.

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

#362

Post by jonnycomputer »

ffsm8 wrote: post #159
jonnycomputer wrote: post #140

My situation is different than a lot of others--I work mostly with code-bases I 100% control--but I just don't use inheritance all that often, and if I do, it's never deeper than one or two levels. Now, I do most of my programming in Python and in JavaScript, and I do like using python's ABCs to specify interfaces for interfaces that I expect to be implemented, but that's mostly the end of it.

I remember the original reason for composition over inheritance to be very specific to Java: you can only inherit one class, but compose your class from multiple interfaces, each of which can have default implemented methods. In python you've got polymorphism, mixins etc, so the reason for this suggestion doesn't really apply. Django heavily uses inheritance for the controllers for example - and it works very well.

I don't really use mixins either, unless it's required by the libraries I'm using. Partly this is habit on my part (and I came to Python from Java). But there is a lot of functionality in python I tend to make only light use of. Like using decorators. I understand them, but they feel like magic, and imo, make code harder to understand if used too much. Same thing with inheritance and multiple inheritance.

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

#363

Post by Supermancho »

lucasyvas wrote: post #317

There is no valid use case I've ever seen where inheritance was better than composition (that does not mean a use case does not exist, but evidence is mounting against it). I would say it's used because every language made a poor decision by building that in as the way to encapsulate reusable logic. i.e., a mistake. Some APIs may expose themselves as requiring you extend a base class, and in that case you might as we…

Inheritance is unidirectional composition. I'm combining the parent with the child.

Making the relationship simple to create and hard to complicate, is why it endures, afaik.

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

#364

Post by Supermancho »

Capricorn2481 wrote: post #342
TheBigSalad wrote: post #325

Earlier quoted context omitted.

Composition implies a level of complexity. There may be a near infinite number of permutations of things that can be combined. If in reality there are only a fixed set of variations, inheritance may model your system in a tighter way. The benefit can be simplicity.

> Composition implies a level of complexity How?

If I combine A and B to make C, I have more than A and B. Now I have A and B and C and the relationship of A to C and B to C. Composition usually creates complexity. Interfaces (via aspects, aspects, traits, whatever) tend to simplify, when the complexity is quantitatively extensive enough to outweigh the cost of the interface complexity creation + the complexity saved by using the interface.

At least, that's how I think of it.

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

#365

Post by nailer »

microflash wrote: post #277
SJC_Hacker wrote: post #268

Earlier quoted context omitted.

>In order to make a new object which implements the `Map` interface, you just have to inherit from the `AbstractMap` base class and implement 1 method, `entrySet` Used to think that way, but I now prefer the alternative - passing function(s)/lambda(s) for the necessary functionality of the dependent class. This way is actually more flexible, as you can change behavior without modifying the override or having a bunch…

It is just a matter of how flexibility you want to expose through your API. Sometimes a rigid and stricter API is the right choice where you want the API itself as the guardrail against non-standard patterns.

Scopes and closures Give you guard rails and don’t require gluing functions to state unnecessary.

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

#366

Post by davidalayachew »

lucasyvas wrote: post #317

There is no valid use case I've ever seen where inheritance was better than composition (that does not mean a use case does not exist, but evidence is mounting against it). I would say it's used because every language made a poor decision by building that in as the way to encapsulate reusable logic. i.e., a mistake. Some APIs may expose themselves as requiring you extend a base class, and in that case you might as we…

I can think of one. For Java at least.

Imagine that I have a class that has 15 methods -- 14 are a perfect fit as is, but 1 of them needs to be completely overwritten.

If I were to do inheritance, I would do `extends` on the class, and then `@Override` the offending method. Problem solved.

If I were to do composition, I could use the Delegation Pattern from the Gang of Four, but that would require me to write 14 do-nothing methods just to be able to override the one.

In general, composition has more use than inheritance. However, inheritance has a non-zero number of use cases where it is a better choice than composition.

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

#367

Post by davidalayachew »

FrustratedMonky wrote: post #204
keiferkif wrote: post #133

Earlier quoted context omitted.

It's funny how easy it is to spot a ChatGPT reply

Do you think it is because it is too verbose? Long winded? A human wouldn't bother to write that much?

For me, it was taking the joke too far. The catwalk comment intro was actually really good, but then it just kept running with it the whole way through. That is not in and of itself a sin, but unless there's a good reason to do so, it dries quickly. You need something to keep it flowing, otherwise it just feels like you really needed to write 8 flamboyant lines mocking HN about inheritance with catwalk references stuck in for all of the lines. Feels forced, almost like you are trying to meet a quota. Which is what makes it feel AI-ish, to me at least.

Definitely one of the better ones though, very impressive. AI really is great at making some very impressive things. But since AI doesn't "get it", a lot of what it produces just feels off or misses the point.

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

#368

Post by ejflick »

tubthumper8 wrote: post #260
CharlieDigital wrote: post #210

Earlier quoted context omitted.

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. Agree 100%. It starts from the earliest programming course where we just teach it all wrong; way to abstract (no pun intended). One point to add to yours: well executed OOP allows for "structural" flow of con…

Interesting articles! I think the first part of the first article immediately introduces an anti-pattern - forcing the user to make an instance of a class just to be able to call a pure function. It's just unnecessary noise, either make them static methods, group them in an object literal, or import the module as a namespace. Adding the "pattern" as a mutable public field is a bit sketchy, and would make it show up i…

> "yeah I have a User, but I don't know if it's a valid User".

This, imo, is one of the big reasons people so easily dismiss OOP. They put whatever data _they think they probably need_ in an object using setters/builders/what have you. This leads to abstractions of data that don't accurately reflect state. They will then let an external entity (service or whatever pattern) manipulate this data. At this point people might as well use something analogous to a C struct where anything can be done to the values. Objects are not managing their own invariants. When you rip this responsibility from an object, then nothing becomes responsible for the validity of an object. Due to this, people wonder why they get bugs and have trouble growing their software.

This also leads to things like "isValid". People don't understand that an object should be constructed with only valid data. The best example I've found of protecting variants and construction of valid objects to be this strategy in F#:

https://fsharpforfunandprofit.com/series/designing-with-type...

I'm yet to find a good way to do this in a language such as Java unfortunately.

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

#369

Post by hnick »

davidalayachew wrote: post #366
lucasyvas wrote: post #317

There is no valid use case I've ever seen where inheritance was better than composition (that does not mean a use case does not exist, but evidence is mounting against it). I would say it's used because every language made a poor decision by building that in as the way to encapsulate reusable logic. i.e., a mistake. Some APIs may expose themselves as requiring you extend a base class, and in that case you might as we…

I can think of one. For Java at least. Imagine that I have a class that has 15 methods -- 14 are a perfect fit as is, but 1 of them needs to be completely overwritten. If I were to do inheritance, I would do `extends` on the class, and then `@Override` the offending method. Problem solved. If I were to do composition, I could use the Delegation Pattern from the Gang of Four, but that would require me to write 14 do-n…

It really depends on what the code variation is, and it can often be a code smell, but I like just adding a flag to the method for simpler cases of this. No complexity or overhead, easy to reason and debug, and you can retain the current method signature with a default-case call to the new method, so no other refactoring required.

It can be inelegant, clunky, and terrible practice if you're doing two totally different things in the method, but I've had a lot of cases recently where it was a nice simple solution that made sense in the context we used it.

For me, one time I like that we use simple OO is a 'DeletedMyClass' extending 'MyClass'- it does everything the same, just has a DeletedDateTime property. A few pages will do an 'is' check (we use C#) and render certain things differently, but apart from that, they both get passed around interchangeably. You could argue you could add an IsDeleted flag, but the default case is that most things we deal with are not deleted, and they shouldn't have to even know about that concept. So to me this is a very useful minimal case of OO.

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

#370

Post by manuel_w »

lamontcg wrote: post #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 t…

> 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.

I agree and like this principle, however, but what would be the difference between the base class and a mixin class then?

Post reply on HN