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.
When did people favor composition over inheritance?
51–60 of 218 posts
Re: When did people favor composition over inheritance?
#52I never liked inheritance. It seems like something that works well in a world where you assume things don’t evolve rapidly. It also feels like it adds mental debt—every new thing needs to comply with old things to stay compatible. Every update has to take into account how old components are working. Probably, the static nature helps big teams and big companies. But I’ve found that some duplicated code is way easier to deal with, especially now that LLMs can generate new code so quickly.
Re: When did people favor composition over inheritance?
#53Each 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…
Same way I see it.
Objects and inheritance are good when you need big contracts. Functions are good when you want small contracts. Sometimes you want big contracts. Sometimes you want small contracts.
Sometimes the right answer is to mix and match.
Re: When did people favor composition over inheritance?
#54Arguably 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.”
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.
Re: When did people favor composition over inheritance?
#55Earlier quoted context omitted.
I'm spoiled by Python's incredibly sane inheritance and I always have to keep in mind that inheritance is a very different beast in other languages.
I'm always surprised by how arrogant and unaware Python developers are. JavaScript/C++/etc developers are quite honest about the flaws in their language. Python developers will stare a horrible flaw in their language and say "I see nothing... BTW JS sucks so hard.". Let me give you just one example of Python's stupid implementation of inheritance. In Python you can initialize a class with a constructor that's not eve…
For what it's worth, pyright highlights the problem in your first example:
t.py:11:20 - error: Argument of type "Self@C" cannot be assigned to parameter "self" of type "B" in function "__init__"
"C*" is not assignable to "B" (reportArgumentType)
1 error, 0 warnings, 0 information
Re: When did people favor composition over inheritance?
#56Earlier quoted context omitted.
"Gluing together in a way that's not inheritance" is useful enough by itself. Most class hierarchies are wrong, and even when they're right people tend to implement th latest and greatest feature by mucking with the hierarchy in a way which generates wrongness, mostly because it's substantially easier, given a hierarchy, to implement the feature that way. Inheritance as a way of sharing code is dangerous. The thing c…
I don't think that it really is a useful enough definition. There are lots of ways to glue things together that aren't inheritance that are very different from each other. I could compose functions together like the Haskell `.`, which does the regular f(g(x)), and I don't think anyone disputes that that is composition, but suppose I have an Erlang-style message passing system between two processes? This is still glui…
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.
Re: When did people favor composition over inheritance?
#57An 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…
Sounds like someone didn’t follow the SOLID principles
Re: When did people favor composition over inheritance?
#58"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…
I have always heard "prefer composition to inheritance" also referred to as "has a" instead of "is a." Meaning: class Dog : Animal; // inheritance class Car: Wheels wheels; // composition
Yep. "Composition" has many meanings, but in the context of "inheritance vs. composition" it's just referring to "x has a y".
Re: When did people favor composition over inheritance?
#59Earlier quoted context omitted.
I don't think that it really is a useful enough definition. There are lots of ways to glue things together that aren't inheritance that are very different from each other. I could compose functions together like the Haskell `.`, which does the regular f(g(x)), and I don't think anyone disputes that that is composition, but suppose I have an Erlang-style message passing system between two processes? This is still glui…
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".
Re: When did people favor composition over inheritance?
#60When I first took an object oriented programming class it was all about inheritance so that's what I tried to use for everything. Then I started writing real programs and realized that inheritance sucked then finally found the succent "Favor composition over inheritance".