8 ms·
Composition should be favored over inheritance whenever feasible. It is not always feasible so many use for inheritance remain. What you can do is make composi
by norswap 7y ago
Composition should be favored over inheritance whenever feasible. It is not always feasible so many use for inheritance remain.
What you can do is make composition easier. Kotlin does this with its delegation system: https://kotlinlang.org/docs/reference/delegation.html https://kotlinlang.org/docs/reference/delegation.html
- jchw 7y agoOf course, it is possible to totally eschew inheritance as a language feature. Go does it nicely and I can’t think of many circumstances where modeling my code has suffered as a result, usually the opposite. That said I don’t claim inheritance to be useless by any means, and I would not use Go for every kind of software.
- norswap 7y agoI didn't claim it is impossible either :) I kinda agree. Still, for an imperative language I think it's a tool I'd like to have in my toolbox, or at least it needs a compelling alternative, which I don't think Go has (1). Of course there are many cases in which you can do perfectly without. (1) I know it has composition through struct embedding, but not real inheritance: a method delegated to the embedded struct can't call back a method on the embedder automatically. If you do know of some other means in which Go can replace this kind of inheritance, I'd be happy to hear about it.