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

131–140 of 218 posts

Re: When did people favor composition over inheritance?

#131

Post by gf000 »

zelphirkalt wrote: post #7
moomin wrote: post #6

Arguably the answer is “When Barbara Liskov invented CLU”. It literally didn’t support inheritance, just implementation of interface and here we have her explaining 15 odd years later why she was right the first time. I used to do a talk about Liskov that included the joke “CLU didn’t support object inheritance. The reason for this is that Barbara Liskov was smarter than Bjarne Stroustrup.”

I mean, it's not that hard to understand, why composition is to be preferred, when you could easily just use composition instead of inheritance. It's just that people, who don't want to think have been cargo-culting inheritance ever since they first heard about it, as they don't think much further than the first reuse of a method through inheritance.

No, it's not a complete replacement for inheritance.

Re: When did people favor composition over inheritance?

#132

Post by Surac »

Coming from C++ and C# I think interface inheritance is good. But code inheritance is bad. I always try to avoid it. The only times I need to use code inheritance is wen I have to use framework classes that have bug or broken behavior I have to repair. Eg: label control in c# copy its text to clipboard on double click in windows.form

Re: When did people favor composition over inheritance?

#133

Post by DonHopkins »

Razengan wrote: post #48

Gameplay logic inherently leans more towards composition, with a little hint of inheritance. You can have players and monsters, which are all types of "characters" or "units", which is inheritance, but instead of having a separate FlyingPlayer and a separate FlyingMonster, which use the same code for flight, you could have a FlyingComponent, which is composition. I've been going all in on composition and it's amazing…

Entity Component System:

https://en.wikipedia.org/wiki/Entity_component_system

Re: When did people favor composition over inheritance?

#134

Post by mrsmrtss »

DeathArrow wrote: post #102
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…

I 100% agree. And even though I use C# which is kind of OOP heavy, I use inheritance and encapsulation as least as possible. I try to use o more functional worklflow, with data separated from functions/methods. I keep data in immutable Records and use methods/functions to transform it, trying to isolate side effects and minimize keeping state. It's a much pleasurable and easier way to work, for me at least. Trying to…

I agree that changing object state and having side effects should be avoided, but you can achieve both immutability and encapsulation very easily with C#:

    public record Thing()
    {
        private string _state = "Initial";
        public Thing Change() => this with { _state = "Changed" };
    }

Re: When did people favor composition over inheritance?

#135

Post by grahamlee »

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…

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 `final` modifier to impose those limits.

Re: When did people favor composition over inheritance?

#136

Post by mrsmrtss »

lll-o-lll wrote: post #19
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.

Diamond inheritance is its own special kind of hell, but “protected virtual” members of java and c# are the “evil at scale” that’s still with us today. An easy pattern that leads to combinatorial explosion beyond the atoms in the universe. Trivially. People need to look at a playing deck. 52 cards, and you get 8×10^67 possible orders of the deck. Don’t replicate this in code.

At least C# methods are not virtual by default like in Java.

Re: When did people favor composition over inheritance?

#137

Post by kragen »

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…

Guess what, lots of people have been building GUI applications without views, much less view controllers, for longer than that. Including Squeak, with Morphic.

Re: When did people favor composition over inheritance?

#138

Post by kryptiskt »

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.

I've programmed C++ for decades and I believe all sane C++ code styles disallow multiple inheritance (possibly excepting pure abstract classes which are nothing but interfaces). I certainly haven't encountered any for a long time even in the OO-heavy code bases I've worked with.

Re: When did people favor composition over inheritance?

#139

Post by sidewndr46 »

kccqzy wrote: post #45
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…

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…

The virtual keyword in c++ is more of a compiler optimization and less of a design decision. C++ doesn't want everyone paying the overhead of virtual function calls like other languages

Re: When did people favor composition over inheritance?

#140

Post by wseqyrku »

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…

> Add to that the fact that "objects" have state, and each class in the hierarchy may add more state, and modify state declared on parents. Perfect combinatory explosion of state and control-flow complexity.

What if you are actually dealing with state and control-flow complexity. I'm curious what would be the "ideal" way to do this in your view. I am trying to implement a navigation system stripping interface design and all the application logic, even at this level it can get pretty complicated.

Post reply on HN