[maxdeviant]

You can use composition to reduce boilerplate as well. Composition > inheritance is something that is emphasized greatly in the React community.

[tigershark]

Composition increases boilerplate code. With simple inheritance hierarchies there is an inherent advantage in this regard. If you use inheritance you don't need to encapsulate the "base" object and implement all the methods of the interfaces doing most of the time just a routing to the base object, you can just extend from the abstract base object and implement only the methods that you need. Obviously if your hierarchy is complex then it is much better to use composition to have a better decoupling, but it has nothing to do with decreasing the boilerplate code. Composition and inheritance are just two tools for different jobs. If someone says Composition > Inheritance it is like saying Screwdriver > Hammer, a complete non-sense. There is no tool that is inherently good or bad, it all depends how the craftsman uses it (or don't) in a good or bad way for the job.

[jdmichal]

> If someone says Composition > Inheritance it is like saying Screwdriver > Hammer, a complete non-sense.

You're stretching a bit too far. Inheritance is nothing but composition with some default implicit virtual method routing. You admit as much in your comment. If you want tools, it's more like a hammer vs a mallet and a prybar. Same tools, same purpose, just one is bundled.

[tigershark]

The purpose is completely different. You use interfaces and composition to decouple the implementation of some objects, you use inheritance to define some object hierarchy. Inheritance specifies the is a relationship, Composition the has a. As you can see these two are totally different concepts.

[jdmichal]

What is an is a relationship? It is the promise that a type implements a contract. That sounds like an interface to me; implementing interfaces also forms is a relationships. Allow interfaces to be externally defined for a type, and now you have Haskell classes or Rust traits. This isn't a new idea I'm proposing here; it's quite workable and very straight-forward.

EDIT: To be clear, in inheritance, the contract being implemented is the implicit contract specified by the parent type. (Assuming you're following the Liskov substitution principle, which you should be.)

[tigershark]

you were not speaking about interfaces, you were speaking about composition. As I said composition and inheritance are two completely different concepts. And I'm not making up the definitions, is a and has a are very well known concepts in computer science. You can argue ad libitum, but this doesn't change the definition. https://en.m.wikipedia.org/wiki/Has-a https://en.m.wikipedia.org/wiki/Is-a

[jdmichal]

I'm starting to feel like you're not actually reading anything I write. I specifically include interfaces. To quote myself:

> Also, maybe eliminate inheritance and force interfaces and composition instead.

Implementing an interface meets all the conditions of an is a relationship; no redefinition is necessary. [0] After all, interfaces are nothing more than abstract base classes with no method bodies to inherit. I haven't argued anywhere that composition defines an is a relationship, so I have no idea where you're pulling that from.

[0] https://en.m.wikipedia.org/wiki/Is-a#Java

EDIT: I really like this article you linked. It has all sorts of things that help me prove my point. For instance, the Rectangle example from the LSP section. If Rectangle were an interface:

    interface IRectangle {
        double getWidth();
        double getHeight();
    }

It's trivial to implement concrete Rectangle and Square classes that don't violate any principles. Inheritance, on the other hand, is pretty much guaranteed to be broken as long as Rectangle is mutable, because Square cannot add additional constraints to Rectangle and still pretend to be a Rectangle in all use-cases.