3 ms·

A problem that only exists in OOP codebases. Just don't do it and avoid the issue entirely.

by sirwhinesalot 2y ago

whattheheckheck 2y ago
What do you work on that avoids oop code bases?
- sunshowers 2y ago
  I've written Rust full time for the last 8 years, being part of teams that have shipped several large, transformative, and basically correct projects. No OOP in sight. It's wonderful!
- sirwhinesalot 2y ago
  At work we sadly have to implement very OOP-y standards with all the bullshit that entails. 11 levels of inheritance with overrides all over the place sure isn't fun to deal with. But for things I do myself I use objects and interfaces strictly as a tool to solve specific problems, not as the overall program structure. Most of the time you just need to turn some bits into other bits with a function, no need to overcomplicate things. The question of if a square is a rectangle or a rectangle is a square is the sort of thing that comes from OOP brain-rot. They're just data, and their "isa" relationship is likely not even relevant to the problem you're actually trying to solve, like displaying them onscreen. A "square" could be a function that makes a rectangle out of a single float. A "rectangle" could be a function that produces a polygon. The concepts need not be modeled as types or objects at all. It depends on the actual use case.
  - taylodl 2y ago
    That's an interesting perspective on inheritance. The problem I see inheritance solving is not having to distribute subtype-specific logic throughout your code base - functions can interact with objects in a generic manner and you get to keep subtype-specific code all in one spot. That's a win. Inheritance isn't the only means for achieving this capability, though. You can also use interfaces and protocols. I prefer to use interfaces. If my class needs to implement an interface than that's explicit: it implements the interface. I can use inheritance if the class really IS-A variant of another class and it can use that base class in fulfilling its obligation in implementing that interface. That's an implementation detail. But the fact it has responsibility for implementing that interface is made explicit.
    - sirwhinesalot 2y ago
      Yeah but that's what I mean by using it as a tool, you're not trying to model some weird taxonomy with your classes (like the square/rectangle situation), you're using a language feature to enable generic code and/or for code reuse, any real-world relationship between the concepts is irrelevant. Inheritance is bad because it enforces a subtyping relationship alongside code reuse and data reuse. It is extremely rare you want all 3 together and even when you think you do there's a rude awakening coming your way, specially if you did the "model real world concepts as a class hierarchy thing." The object-relational mismatch is a weakness of the object side, not of the relational. Use the right tool for the job and forget about stupid programming paradigms.

A problem that only exists in OOP codebases. Just don't do it and avoid the issue entirely.

whattheheckheck 2y ago

What do you work on that avoids oop code bases?

sunshowers 2y ago
I've written Rust full time for the last 8 years, being part of teams that have shipped several large, transformative, and basically correct projects. No OOP in sight. It's wonderful!
sirwhinesalot 2y ago
At work we sadly have to implement very OOP-y standards with all the bullshit that entails. 11 levels of inheritance with overrides all over the place sure isn't fun to deal with. But for things I do myself I use objects and interfaces strictly as a tool to solve specific problems, not as the overall program structure. Most of the time you just need to turn some bits into other bits with a function, no need to overcomplicate things. The question of if a square is a rectangle or a rectangle is a square is the sort of thing that comes from OOP brain-rot. They're just data, and their "isa" relationship is likely not even relevant to the problem you're actually trying to solve, like displaying them onscreen. A "square" could be a function that makes a rectangle out of a single float. A "rectangle" could be a function that produces a polygon. The concepts need not be modeled as types or objects at all. It depends on the actual use case.
- taylodl 2y ago
  That's an interesting perspective on inheritance. The problem I see inheritance solving is not having to distribute subtype-specific logic throughout your code base - functions can interact with objects in a generic manner and you get to keep subtype-specific code all in one spot. That's a win. Inheritance isn't the only means for achieving this capability, though. You can also use interfaces and protocols. I prefer to use interfaces. If my class needs to implement an interface than that's explicit: it implements the interface. I can use inheritance if the class really IS-A variant of another class and it can use that base class in fulfilling its obligation in implementing that interface. That's an implementation detail. But the fact it has responsibility for implementing that interface is made explicit.
  - sirwhinesalot 2y ago
    Yeah but that's what I mean by using it as a tool, you're not trying to model some weird taxonomy with your classes (like the square/rectangle situation), you're using a language feature to enable generic code and/or for code reuse, any real-world relationship between the concepts is irrelevant. Inheritance is bad because it enforces a subtyping relationship alongside code reuse and data reuse. It is extremely rare you want all 3 together and even when you think you do there's a rude awakening coming your way, specially if you did the "model real world concepts as a class hierarchy thing." The object-relational mismatch is a weakness of the object side, not of the relational. Use the right tool for the job and forget about stupid programming paradigms.