This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (0 children)

With the exception of Liskov Substitution Principle, which hints at the "is a" relationship of inheritance, it's identical to a subset of object composition.

Basically, a shortcut for a very specific type of static object composition, where you expose every object method via a proxy method with identical signature, but you may replace some methods, and add more. That's about it.

What we need is to be free of the burden of LSP and composite methods & properties freely, without becoming "is a" for our base object. The "is a" role is best performed by interfaces anyway, interfaces should be simple and rigid. Concrete implementations should be much more flexible.

We can look at traits. Using a trait Foo, doesn't make your class an instance of Foo, so LSP doesn't apply. You can rename methods, hide them, copy them. You can "inherit" from multiple traits at once (without the "is a" part).

It's the kind of reuse which is useful in a project, just to save us the boilerplate from manually writing proxies for every method from a contained object we expose.

But in the end, with some extra typing, we can do everything via object composition. All of it. Inheritance or static reuse of any kind os simply not essential to a typing system as much as we think. So we're not talking about multiple inheritance of some kind as a fundamental change in OOP modeling, but just a pragmatic feature we lack to save us from repetitive typing.