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

When did people favor composition over inheritance?

sicpers.info

Post reply on HN
Print view View original

161–170 of 218 posts

Re: When did people favor composition over inheritance?

#161

Post by tyleo »

My personal preference for composition over inheritance is that it forces callers to call the owned-object’s methods directly rather than automatically through inheritance.

There is more typing/boilerplate but when you read the class file you get a full picture of what’s happening rather than some parts happening automatically in a different file.

I like to say that code should be written with a reader bias: the singular writer should do more work if it makes the class more obvious for the multitude of readers. I feel like composition is a good example of that.

Re: When did people favor composition over inheritance?

#162

Post by DarkNova6 »

tyleo wrote: post #161

My personal preference for composition over inheritance is that it forces callers to call the owned-object’s methods directly rather than automatically through inheritance. There is more typing/boilerplate but when you read the class file you get a full picture of what’s happening rather than some parts happening automatically in a different file. I like to say that code should be written with a reader bias: the sing…

The way I like yo phrase it: concretion over indirection.

Re: When did people favor composition over inheritance?

#163

Post by ferd »

OrderlyTiamat wrote: post #112
ferd wrote: post #43

An important point not mentioned by the article is that of "co-recursion" with inheritance (of implementation). That is: an instance of a subclass calls a method defined on a parent class, which in turn may call a method that's been overridden by the subclass (or even another sub-subclass in the hierarchy) and that one in turn may call another parent method, and so on. It can easily become a pinball of calls around t…

> It can easily become a pinball of calls around the hierarchy. This is why hierarchies should have limited depth. I'd argue some amount of "co-recursion" is to be expected: after all the point of the child class is to reuse logic of the parent but to overwrite some logic. But if the lineage goes too deep, it becomes hard to follow. > every time you modify a class, you must review the inner implementation of all othe…

> I'd argue some amount of "co-recursion" is to be expected: after all the point of the child class is to reuse logic of the parent

That's the point: You can reuse code without paying that price of inheritance. You DON'T have to expect co-recursion or shared state just for "code-reuse".

And, I think, is the key point: Behavior inheritance is NOT a good technique for code-reuse... Type-inheritance, however, IS good for abstraction, for defining boundaries, to enable polymorphism.

> I'd say this is a fact of life for all pieces of code which are reused more than once

But you want to minimize that complexity. If you call a pure function, you know it only depends on its arguments... done. If you can a method on a mutable object, you have to read its implementation line-by-line, you have to navigate a web of possibly polymorphic calls which may even modify shared state.

> This is another reason why low coupling high cohesion is so important

exactly. Now, I would phrase it the other way around though: "... low coupling high cohesion is so important..." that's the reason why using inheritance of implementation for code-reuse is often a bad idea.

Re: When did people favor composition over inheritance?

#164

Post by imglorp »

creata wrote: post #54
Scubabear68 wrote: post #8

Earlier quoted context omitted.

There is a reason C++ devs and only C++ devs have nightmares of diamond inheritance. Oh the damage that language has done to a generation, but at least it is largely passed us now.

> at least it is largely passed us now What does this mean? There doesn't seem to be a popular alternative to C++ yet, unfortunately.

There's a growing group that believes no new projects should be started in C/C++ due to its lack of memory safety guarantees. Obviously we should be managing existing projects, but 1973 is calling, it's time to retire into long-tail maintenance mode.

https://security.googleblog.com/2025/11/rust-in-android-move...

Re: When did people favor composition over inheritance?

#165

Post by kccqzy »

nine_k wrote: post #99
kccqzy wrote: post #36

Earlier quoted context omitted.

Every language that permits diamond inheritance causes the devs who dare to use this feature at least some nightmare. It's not a C++ issue.

It's also cultural, possibily. Python supports diamond inheritance, and clearly states how it handles it (it ends up virtual in C++ terms). But in like 20 years of working with Python I can't remember encountering diamond inheritance in the wild once.

Diamond inheritance is in fact highly pervasive in Python. The reason is that every class is a subclass of object since Python 3 (Python 2 allows classic classes that are different). So every single time you use multiple inheritance you have diamond inheritance. Some of this diamond inheritance is totally innocuous, but mostly not, because a lot of classes override dunder methods on object like __setattr__. It was Guido van Rossum himself that observed the prevalence of diamond inheritance that led to Python 2.3 fixing the MRO, and introducing the super() function to make multiple inheritance sane.

You should read his essay: https://www.python.org/download/releases/2.2/descrintro/

Re: When did people favor composition over inheritance?

#166

Post by voxleone »

The split between inheritance-heavy OOP and composition-first OOP really just reflects how software design has shifted toward approaches that handle change better. Inheritance still solves real problems, but for most modern, fast-changing systems, composition usually offers a smoother path.

Of course, developers mix and match depending on what the situation calls for. But knowing how these two mindsets differ can make it easier to build code that stays clean and easy to evolve.

And as programming continues to pull ideas from functional, reactive, and declarative styles, the compositional way of thinking will probably stay right at the heart of how we approach object-oriented design.

https://d1gesto.blogspot.com/2025/05/the-split-in-oop-compos...

Re: When did people favor composition over inheritance?

#167

Post by oh_my_goodness »

mrkeen wrote: post #115
oh_my_goodness wrote: post #18

Yeah inheritance is just not the point of OO. It’s fine but it’s not what’s really useful.

What is the point of OO?

The main point is the same as the Dewey Decimal System. Keep things tucked away yet findable. Make a huge code base useful to people who didn't write it themselves.

Re: When did people favor composition over inheritance?

#168

Post by franga2000 »

ferd wrote: post #43

An important point not mentioned by the article is that of "co-recursion" with inheritance (of implementation). That is: an instance of a subclass calls a method defined on a parent class, which in turn may call a method that's been overridden by the subclass (or even another sub-subclass in the hierarchy) and that one in turn may call another parent method, and so on. It can easily become a pinball of calls around t…

If the author intended a function to be overridable and designed the class as such, none of this is a problem. I never need to look inside the parent class, let alone the entire hierarchy.

On the flip side, if the author didn't want to let me do that, I really appreciate having the ability to do it anyways, even if it means tighter coupling for that one part.

Re: When did people favor composition over inheritance?

#169

Post by simplesocieties »

seanalltogether wrote: post #124

I've been building gui applications for the past 20 years and I couldn't imagine doing it without an inheritance model. There's so much scaffolding needed to build components and combine them into a working view. Sure inheritance can be bad in the data layer because you don't want to handcuff yourself to bad data expectations. But building out views and view controllers, there's a lot of logic you don't want to keep…

And yet somehow the Zed team managed to do it with gpui and rust.
Post reply on HN