3 ms·
This has been coming up a lot lately. It seems to me that a new generation of developers are simply rejecting oo-paradigms because they are oo, without an in-d
by caspper69 2y ago
This has been coming up a lot lately.
It seems to me that a new generation of developers are simply rejecting oo-paradigms because they are oo, without an in-depth analysis.
I agree with the general consensus that oo inheritance hierarchies of the past became too deep and were overwhelming, but subtyping has a place.
Because interfaces are stateless, you generally cannot completely implement required interface functionality without wiring them up to each individual object, resulting in a lot of boilerplate code repetition.
This is exacerbated in GUI programming, for example, where subtyping makes a lot of sense (and doesn't devolve into Animal -> Rabbit nonsense).
With subtyping, you can take an object that is 95% of another object and just override where necessary.
I also don't believe composition provides the same level of encapsulation that can be achieved through traditional class-based oo. There seems to be this prevailing view that oo is all about inheritance, when the truth is that oo was really about encapsulation and isolation. You only expose what you need to, and objects (whether they be classes or structs or whatever) can be built and tested without fear of code collisions or meddling from the outside view.
I will concede that interfaces can and do provide a level of encapsulation, but in practice, it's just clunky.
Just look at some Rust objects and the sheer number of traits that they must be aware of and implement by hand. It's piecemeal when it could be one and done.
And please understand, I'm not talking about "...in the beginning there was a GObject, and that GObject bequeathed to...and..."
- vips7L 2y agoInheritance is just a tool. It’s insane to reject it outright just because someone can use it incorrectly. It does some things extremely well and better than composition.
- int_19h 2y agoThis boilerplate repetition that you refer to is only necessary when doing composition because the languages don't provide the requisite syntactic sugar for it, the way they do for inheritance. This is very unfortunate but totally fixable.
- caspper69 2y agoI'd be interested to understand how / what types of proposals exist to solve this very real ergonomic issue. As I stated in my original post, the implementations of interfaces/composition that I have used (primarily C# and Rust) are stateless, so you must always re-implement. And honestly, if Rust were to say, allow the specification of struct members in trait definitions, one could argue that their structs are really sealed/final classes, just using different keywords. I am genuinely curious, because I do believe that people have a valid point that composition does tend to lead to less object spaghetti than inheritance, even if I can't quite pinpoint why from a purely theoretical standpoint (my belief is that they're "holding it wrong").
- int_19h 2y agoFor example, Kotlin has syntactic sugar specifically to implement interfaces by delegating to an inner object (with overrides etc): https://kotlinlang.org/docs/delegation.html https://kotlinlang.org/docs/delegation.html
- impulsivepuppet 2y agoThere are more interpretations of "OO" than there are people, but the overall direction is that OO isn't a panacea for code maintainability, and some frameworks ahem Spring create a mental model at times so distant from OOP, that I might as well have written everything in Python. I gain nothing from having classes when one half are records and the other half are singletons.