7 ms·

Overuse/misuse of inheritance has triggered hatred of OOP among many software developers...

by pulse7 5y ago

brobdingnagians 5y ago
Yeah, I've loved classes and OOP for a long time, but lately I've been on a project that is going into more and more contortions and complexity to make everything fit a theoretical ideal. It's revived my interest in learning FP languages to avoid the arcane complexity that some people make out of OOP.
- lelag 5y ago
  I feel complexity creep is often inevitable regardless of the paradigm or technology you use. Programmers have varying levels of complexity they can handle and the systems generally naturally grow to match the complexity that the people that work on them can support. Experienced programmers will manage to keep that complexity creep under control for longer and smarter programmers will manage to keep working on complex systems that lesser peers would have no chance to understand. But eventually, unless the software has a very clear functional boundary which is often not the case for business software, software will start to become increasingly complex and dev velocity will slow down, quality will drop... I've seen this happening at all skill levels regardless of the languages and paradigms used.
  - qayxc 5y ago
    > I feel complexity creep is often inevitable regardless of the paradigm or technology you use. This. I always love toy examples that look so nice, concise, and elegant. Until you add proper error-handling and corner cases that is; then all of a sudden it doesn't look half as concise, elegant, and beautiful anymore...
  - MillenialMan 5y ago
    The problem with inheritance-heavy OO is that complexity creep rapidly makes the code completely unreadable and incredibly hard to work with (and basically impossible to refactor), rather than just making it more branchy and complex.
throwaway894345 5y ago
I’ll go out on a limb and posit that there are virtually no valid uses of (implementation) inheritance. Perhaps one valid use is getting rid of delegation boilerplate (e.g., normally you would compose one object inside another but you want the outer object methods to delegate to the inner object methods but you don’t want to have to write N function definitions that just call the same methods on the inner object so instead your outer object inherits from your inner object). This problem is better solved by something like Go’s struct embedding since it doesn’t do anything more than this kind of automatic delegation. And if you get rid of inheritance, there is very little left to distinguish OOP from procedural programming like one would do in C or Go. And this is the semantic problem: no one really agrees on what OOP is and proponents will rebut any criticism with “that’s not true OOP”. Any definitions of OOP that aren’t easily assailable are also indistinguishable from other existing paradigms. Downvoters: i’m very interested in your opinions about why I’m wrong and specifically when you think inheritance is appropriate. Everyone says “there’s a time and a place!” but no one articulates when/where beyond cat/dog/animal toy examples.
- pulse7 5y ago
  Some cases where inheritance may be useful: UI widget libraries, graphical/drawing objects, (very similar) stream implementations. All this can of course be done without inheritance, but with inheritance it is much more elegant.
  - throwaway894345 5y ago
    Thank you for responding. I probably agree with the widget library example, but even here a widget library is just one way of implementing a GUI toolkit and perhaps it’s just the emergent result of an OOP-based approach (and consequently there are some really brutal tradeoffs in using a widget-based approach for a toolkit). To that point, with respect to general drawing libraries, I don’t think that OOP/inheritance yields a more elegant design than a reactive or intermediate mode approach (perhaps these terms only apply to GUI, but I imagine there are parallel terms for graphical APIs in general). Even though I concede narrowly on the widget GUI library point, these libraries are so very rare that I don’t think it’s a very compelling case for OOP proponents. I suspect they’d like to argue that there are appropriate uses for inheritance in most applications and not just the odd GUI library. Otherwise I don’t think it even merits first-class language support (why bother with an `extends` keyword if it’s only going to be useful in the rarest of libraries?).
AdieuToLogic 5y ago
> Overuse/misuse of inheritance has triggered hatred of OOP among many software developers... "It is not the tools we use that make us good, but rather how we employ them."[0] 0 - https://en.wiktionary.org/wiki/a_bad_workman_always_blames_his_tools https://en.wiktionary.org/wiki/a_bad_workman_always_blames_h...

Overuse/misuse of inheritance has triggered hatred of OOP among many software developers...

by pulse7 5y ago

Overuse/misuse of inheritance has triggered hatred of OOP among many software developers...

Yeah, I've loved classes and OOP for a long time, but lately I've been on a project that is going into more and more contortions and complexity to make everything fit a theoretical ideal. It's revived my interest in learning FP languages to avoid the arcane complexity that some people make out of OOP.

lelag 5y ago
I feel complexity creep is often inevitable regardless of the paradigm or technology you use. Programmers have varying levels of complexity they can handle and the systems generally naturally grow to match the complexity that the people that work on them can support. Experienced programmers will manage to keep that complexity creep under control for longer and smarter programmers will manage to keep working on complex systems that lesser peers would have no chance to understand. But eventually, unless the software has a very clear functional boundary which is often not the case for business software, software will start to become increasingly complex and dev velocity will slow down, quality will drop... I've seen this happening at all skill levels regardless of the languages and paradigms used.
- qayxc 5y ago
  > I feel complexity creep is often inevitable regardless of the paradigm or technology you use. This. I always love toy examples that look so nice, concise, and elegant. Until you add proper error-handling and corner cases that is; then all of a sudden it doesn't look half as concise, elegant, and beautiful anymore...
- MillenialMan 5y ago
  The problem with inheritance-heavy OO is that complexity creep rapidly makes the code completely unreadable and incredibly hard to work with (and basically impossible to refactor), rather than just making it more branchy and complex.

throwaway894345 5y ago

I’ll go out on a limb and posit that there are virtually no valid uses of (implementation) inheritance. Perhaps one valid use is getting rid of delegation boilerplate (e.g., normally you would compose one object inside another but you want the outer object methods to delegate to the inner object methods but you don’t want to have to write N function definitions that just call the same methods on the inner object so instead your outer object inherits from your inner object). This problem is better solved by something like Go’s struct embedding since it doesn’t do anything more than this kind of automatic delegation. And if you get rid of inheritance, there is very little left to distinguish OOP from procedural programming like one would do in C or Go. And this is the semantic problem: no one really agrees on what OOP is and proponents will rebut any criticism with “that’s not true OOP”. Any definitions of OOP that aren’t easily assailable are also indistinguishable from other existing paradigms. Downvoters: i’m very interested in your opinions about why I’m wrong and specifically when you think inheritance is appropriate. Everyone says “there’s a time and a place!” but no one articulates when/where beyond cat/dog/animal toy examples.

pulse7 5y ago
Some cases where inheritance may be useful: UI widget libraries, graphical/drawing objects, (very similar) stream implementations. All this can of course be done without inheritance, but with inheritance it is much more elegant.
- throwaway894345 5y ago
  Thank you for responding. I probably agree with the widget library example, but even here a widget library is just one way of implementing a GUI toolkit and perhaps it’s just the emergent result of an OOP-based approach (and consequently there are some really brutal tradeoffs in using a widget-based approach for a toolkit). To that point, with respect to general drawing libraries, I don’t think that OOP/inheritance yields a more elegant design than a reactive or intermediate mode approach (perhaps these terms only apply to GUI, but I imagine there are parallel terms for graphical APIs in general). Even though I concede narrowly on the widget GUI library point, these libraries are so very rare that I don’t think it’s a very compelling case for OOP proponents. I suspect they’d like to argue that there are appropriate uses for inheritance in most applications and not just the odd GUI library. Otherwise I don’t think it even merits first-class language support (why bother with an `extends` keyword if it’s only going to be useful in the rarest of libraries?).

AdieuToLogic 5y ago

> Overuse/misuse of inheritance has triggered hatred of OOP among many software developers... "It is not the tools we use that make us good, but rather how we employ them."[0] 0 - https://en.wiktionary.org/wiki/a_bad_workman_always_blames_his_tools https://en.wiktionary.org/wiki/a_bad_workman_always_blames_h...