Live data from Hacker News

When did people favor composition over inheritance?

sicpers.info

81–90 of 218 posts

Re: When did people favor composition over inheritance?

#81
post #74

Earlier quoted context omitted.

> There are many paradigms and each one has its place. That's a thought-terminating cliché. The argument against inheritance has been laid out pretty clearly. It's reasonable to rebut that argument. It's not reasonable to say, "you shouldn't criticize inheritance because Everything Has Its Place." Everything does not have its place. Sometimes we discover that something is harmful and we just stop using it.

> Sometimes we discover that something is harmful and we just stop using it. And that is not remotely the case here. So yeah, there are many paradigms and each has its place.

> And that is not remotely the case here.

Isn't it? People have written extensively about why we should prefer composition to inheritance, and you haven't mounted any defence of inheritance beyond the thought-terminating cliché that it "has its place."

Re: When did people favor composition over inheritance?

#82
post #70

Each has its place. There's some things that inheritance makes possible, and some things that are best handled by composition. I use both, quite frequently. It Depends™. Composition can add a lot of complexity to a design, and give bugs a lot more corners to hide in, but inheritance can be such a clumsy tool, that it just shouldn't be used for some tasks. That goes for almost everything in software. Becoming zealous…

I dunno. It's easy to say, "there are trade-offs, it depends" any time two things are compared, and it's never entirely untrue. However, sometimes one option is just generally worse than the other. I'm not saying it's malpractice to use inheritance or anything, but it's a tool I definitely hesitate to reach for. Go and Rust removed inheritance entirely, and I'd say those languages are better-off without it.

There’s definitely stuff that it enables. I’ve been writing software since before it was a thing, and it was almost magic, when I first learned about it.

I also saw why it fell from grace, but I already knew, by then, that it was no panacea. I learned, on my own, that composition was often a better pattern, and I learned that, back in the 1980s.

Not worth arguing about, but I do find absolutism to be almost offensive, and there’s a damn lot of that, in software development.

Re: When did people favor composition over inheritance?

#84

Each has its place. There's some things that inheritance makes possible, and some things that are best handled by composition. I use both, quite frequently. It Depends™. Composition can add a lot of complexity to a design, and give bugs a lot more corners to hide in, but inheritance can be such a clumsy tool, that it just shouldn't be used for some tasks. That goes for almost everything in software. Becoming zealous…

Sure, but "favor x over y" or, put another way, "use y only if x is unsuitable" is compatible with this. Nothing in "prefer composition over inheritance" says that composition is the only correct way.

No, but I often see folks use it as a bludgeon for dogma.

Re: When did people favor composition over inheritance?

#85
post #59
post #56

Earlier quoted context omitted.

But both of those avoid the pitfalls of inheritance. "Othering" is a common phenomenon, and I think it's useful when creating an appropriate definition of composition.

But I don't think it's terribly useful; there are plenty of things that you could do that the people who coined the term would definitely not agree with. Instead of inheritance, I could just copy and paste lots of different functions for different types. This would be different than inheritance but I don't think it would count as "composition", and it's certainly not something you should "prefer".

That's fair. I'd agree that isn't composition. I'm not sure the thing you describe is worse than inheritance.... It's not composition though.

Re: When did people favor composition over inheritance?

#86
post #74
post #51

How about not favoring anything. There are many paradigms and each one has its place. Franky I do not really understand why do developers fight these religious wars about languages, frameworks etc.

> There are many paradigms and each one has its place. That's a thought-terminating cliché. The argument against inheritance has been laid out pretty clearly. It's reasonable to rebut that argument. It's not reasonable to say, "you shouldn't criticize inheritance because Everything Has Its Place." Everything does not have its place. Sometimes we discover that something is harmful and we just stop using it.

Em.. I’m quite nitpicky and want to do the opposite of “thought-terminating”.

I’m for encouraging best practice, but most things do have its place. I present to this court two examples:“premature optimisation is root of all evil” and “goto statement considered harmful”.

Both well accepted as things should be avoided for good reasons (incl. but not limited to, preserving sanity of coworkers)

But both definitely “have its place”. First one’s place is legitimized (with nuance) by author himself in second part of same sentence. The latter one (goto) is routinely used by linux devs (random example: https://github.com/torvalds/linux/blob/master/fs/ext4/balloc...)

> we just stop using it. We minimise/restrict the usage.

Re: When did people favor composition over inheritance?

#87
I am always bemused when i see articles like these. Do people not have an understanding of fundamental Software Engineering principles from OGs like Parnas/Liskov/etc.?

The fundamental idea is that of Abstraction which can be defined as the discovery/invention of "higher-level concepts" from more primitive "lower-level concepts" and then reasoning and manipulating at the higher-level. This abstraction is based on structure and/or behavioural attributes.

In order to manage the complexity inherent in the building of large systems certain fundamental aspects were identified as highly desirable. They are Separation-Of-Concerns, Modularization, Reuse and Information-Hiding.

The crucial point to understand is that Abstraction does not imply any of the above aspects! A good example are Mathematical Abstractions. But because for Software we desire the above aspects for our system-as-a-whole we learn to combine them with our Abstractions. This is why we have so many different styles of Programming (i.e. Imperative/OO/Functional/Logic/etc.).

Viewed in the above light the relation between Inheritance and Composition becomes clear. They are just different ways of emphasizing different combinations of the above aspects for your abstractions based on your design needs.

References:

1) Software Fundamentals: Collected Papers by David L. Parnas.

2) Program Development in Java: Abstraction, Specification, and Object-Oriented Design by Barbara Liskov and John Guttag.

3) Multi-Paradigm Design for C++ by James Coplien.

Re: When did people favor composition over inheritance?

#88
post #50
post #45

Earlier quoted context omitted.

This is only the case when the language does not distinguish between methods that can be overridden versus those that cannot. C++ gives you the keyword "virtual" to put in front of each member function that you want to opt into this behavior, and in my experience people tend to give it some thought on which should be virtual. So I rarely have this issue in C++. But in languages like Python where everything is overrid…

Good point. In Java and many other languages you can opt out instead... which might make a big difference. Is it more of a "cultural" thing?... again, many frameworks encourage it by design, and so do many courses/tutorials... so those devs would be happy to put "virtual" everywhere in C++

heh, i have seen programmers using virtual everywhere, because they were lazy to use declspec(dll_export) on windows system :)

Re: When did people favor composition over inheritance?

#89
post #81

Earlier quoted context omitted.

> Sometimes we discover that something is harmful and we just stop using it. And that is not remotely the case here. So yeah, there are many paradigms and each has its place.

> And that is not remotely the case here. Isn't it? People have written extensively about why we should prefer composition to inheritance, and you haven't mounted any defence of inheritance beyond the thought-terminating cliché that it "has its place."

I use both where choosing what I believe is appropriate for particular case.

Frankly I do not give rat's ass about what "People have written extensively". From what I read most of it sounds like spoken by politician: look Jimmy, someone can do a bad thing with it. Well fuckin don't do a bad thing.

So much over very simple and primitive thing: John HAS a key vs dog IS an animal. Both are valid and proper.

>"you haven't mounted any defense"

Why would I bother. It does not need a defense. It is like do not use Java because it encourages FactoryFactoryFactory, 20 level of abstraction etc. Well it does not. Architecture astronauts do it and I am not one of those

Re: When did people favor composition over inheritance?

#90
post #74
post #51

How about not favoring anything. There are many paradigms and each one has its place. Franky I do not really understand why do developers fight these religious wars about languages, frameworks etc.

> There are many paradigms and each one has its place. That's a thought-terminating cliché. The argument against inheritance has been laid out pretty clearly. It's reasonable to rebut that argument. It's not reasonable to say, "you shouldn't criticize inheritance because Everything Has Its Place." Everything does not have its place. Sometimes we discover that something is harmful and we just stop using it.

>""you shouldn't criticize inheritance"

I was not talking about criticizing. Valid critique us useful and deserved. And this concerns composition as well as any other area. I was talking about crusades by programmers.

Post reply on HN