Live data from Hacker News

When did people favor composition over inheritance?

sicpers.info

211–218 of 218 posts

Re: When did people favor composition over inheritance?

#211
post #30

"Composition" is a word that can mean several things, and without having read the original source I never really understood which version they mean. As a rule, I've always viewed "composition" as "gluing together things that don't know necessarily know about each other", and that definition works well enough, but that doesn't necessarily eliminate inheritance. So then I start thinking in less-useful, more abstract de…

Article author here. Your idea "gluing together things that don't know necessarily know about each other" is basically what the GoF book means: composition is "this object has a reference to that object and uses its public API". They don't mean "this object ontologically contains an instance of that object" in the sense that a car "has" an engine, which is a narrower definition of composition that people frequently use.

It's that broader version of composition—particularly in its extreme realization, delegation—that underlies a lot of the behavioral patterns in the book. For example, the State and Strategy patterns boil down to "this object relies on another object to fill in the behavior here, and there are ways to choose what that other object is", which is something it's easy to arrange with subclassing and the only point of the pattern is to avoid subclassing.

Re: When did people favor composition over inheritance?

#212
post #201

Earlier quoted context omitted.

Author here. I wrote “ But even a modestly more recent language like Java has visibility attributes that let a class control what its subtypes can view or change, meaning that any modification in a subclass can be designed before we even know that a subtype is needed.” which covers your situation: if you need to ensure that subtypes use the supertype’s behaviour in limited ways, use the visibility modifiers and `fina…

The fact that Java had to add a whole extra set of keywords to control this indicates that this is a site of complexity. Since it isn't needed for composition, it's a site of unnecessary complexity.

What you lose by using composition is that the composing object is no longer a subtype of the constituent object, so you can't use it as a "decoration" of the original object in a program that expects an instance of the original.

Re: When did people favor composition over inheritance?

#213

In Eiffel we have multiple inheritance. It's such a powerful tool. And a natural way to model the world. For example if you think of your typical OOP book You have Vehicles with engines * cars that move on roads * planes that move on air * and boats that move on water. But then comes an aqua-plane and it breaks your inheritance tree! But with multiple inheritance is the most natural thing to have a plane that is also…

My programs are not full of engines and cars and planes and boats and aquaplanes.

These metaphors used to teach OOP back in the day seemed appealing but never proved their worth in actual software design and implementation.

Re: When did people favor composition over inheritance?

#214

Earlier quoted context omitted.

It's not crazy at all, especially since majority of programming is about digitalization of real world things/processed. eBay, Tinder, Youtube, Robinhood, etc, etc. Those are all real world things that are now represented in digital world and adjusted for that. Also "world" doesn't imply "physical", but that's different matter. And at the end of the day that was not wildly crazy, but wildly successful! Such school of…

Wildy successful does not mean a good idea. > Such school of thinking enabled generations of software engineers who created all this digital world. Same could be said for imperative or functional programming for that matter.

As far as I know OOP has orders of magnitude higher market share than FP.

>Wildy successful does not mean a good idea.

Sure, but if there was FP instead of OOP, then would current digital world be better, as big, safer?

Who knows?

Re: When did people favor composition over inheritance?

#215
post #204
post #177

Earlier quoted context omitted.

> So much over very simple and primitive thing: John HAS a key vs dog IS an animal. Both are valid and proper. I don't think so. "Having" vs "being" are descended from an overly simulationist notion of program design. The fact that John has a key in real life does not suggest that this relationship should be represented by an object John which owns an object Key. I think this kind of ontological approach is behind a…

>"The fact that John has a key in real life does not suggest that this relationship should be represented by an object" Exactly and that is my point. If you came up with the set of real business entities, their interaction rules and constraints we would have something to discuss and as a curious person and former scientist I would enjoy it. However blanket statements like "one should not use XYZ some abstract communi…

> However blanket statements like "one should not use XYZ some abstract community thinks so" to me have near zero value.

Come on, you don't believe this. How about a blanket statement like, "one should not use asbestos insulation in buildings because some oncologists think so"? Is that an "abstract statement" which we shouldn't waste time on? Don't be obtuse. Abstract best practices are valuable sometimes.

> Come to a company whose life depends on software running their business [...] and tell them [...] "rewrite it in Rust".

Obviously a full rewrite isn't typically viable. An approach where the path for new contributions is gradually pivoted to Rust can be much more practical. Google's done this with Android to the tune of a 1000x reduction in the density of memory safety vulnerabilities¹, and that matters. Android vulnerabilities can ruin lives. CrowdStrike's life depended on a piece of memory-unsafe software, and look how that turned out. Don't act like software safety & quality aren't serious concerns.

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

> my craft is to design and implement robust solutions for clients [...] I do not find arguing abstract concepts disregarding of particular situation having much value.

Again, imagine a housing contractor saying in response to an "abstract discussion" about asbestos insulation. Abstract concepts have concrete consequences. And don't tell me the asbestos example is too extreme, because the consequences of the CrowdStrike bug were extreme too. Software quality matters.

Re: When did people favor composition over inheritance?

#216
post #201

Earlier quoted context omitted.

The fact that Java had to add a whole extra set of keywords to control this indicates that this is a site of complexity. Since it isn't needed for composition, it's a site of unnecessary complexity.

What you lose by using composition is that the composing object is no longer a subtype of the constituent object, so you can't use it as a "decoration" of the original object in a program that expects an instance of the original.

It can be, if the composing object re-implements the constituent object's interface. This way, code reuse and polymorphism are orthogonal features, which I think is better. If you want both, you can do both, but inheritance pushes you toward using both even when you only need one.

Re: When did people favor composition over inheritance?

#217
post #202
post #142

Earlier quoted context omitted.

> Knowing that there are two constructors that exist for normal, non-native, Python classes, and that the basic constructoe Class.__new__, and that the constructor Class() itself calls Class.__new__() and then, if Class.__new__() returns an instance i of Class, also calls Class.__init__(i) before returning i, is pretty basic Python knowledge. I didn't know most of that, and I've performed in a nightclub in Python, ma…

Don't you mean 0Python?

I see what you did there.

Re: When did people favor composition over inheritance?

#218
post #215
post #204

Earlier quoted context omitted.

>"The fact that John has a key in real life does not suggest that this relationship should be represented by an object" Exactly and that is my point. If you came up with the set of real business entities, their interaction rules and constraints we would have something to discuss and as a curious person and former scientist I would enjoy it. However blanket statements like "one should not use XYZ some abstract communi…

> However blanket statements like "one should not use XYZ some abstract community thinks so" to me have near zero value. Come on, you don't believe this. How about a blanket statement like, "one should not use asbestos insulation in buildings because some oncologists think so"? Is that an "abstract statement" which we shouldn't waste time on? Don't be obtuse. Abstract best practices are valuable sometimes. > Come to…

Obviously we live on a different planets.
Post reply on HN