4 ms·
No, not even remotely. I've found that OOP has too many footguns and becomes a nightmare to debug. in contrast, I find that e.g traits in Rust (insert equivale
by Klonoar 4y ago
No, not even remotely.
I've found that OOP has too many footguns and becomes a nightmare to debug. in contrast, I find that e.g traits in Rust (insert equivalent for your language of choice here, I'm aware Rust isn't the only one with it) are a much cleaner fit. I'm not really sure what the official term is, but I refer to it as Composition-based programming. It sits in a perfect middle ground of being object-oriented-ish without letting people go hog wild.
This all said, I find codebases that use only "functions & data" to be very cumbersome as well. We have patterns for encapsulation that have kind of gotten thrown out the window over the years and it's frustrating. Too many of these codebases feel like they have an inadvertent bus factor of one due to the code being so un-encapsulated, and it's one or two people who really know how it all works.
(As a side note, I never got the hate for JS classes - I know they don't behave like true classes in other languages, but I considered that a plus. React was 100x more approachable with them.)
- undefeated 4y agoAgreed. I recently had to write a package with some quite complex type inference requirements, so I had to resort to classes. I've since had to issue 17 patches (it's been 3 weeks) even though the package has 100% test coverage.
- parentheses 4y agoFinally coming back to this and I do agree with a lot of what you say: traits + data types + functions are the right mixture. It gives you immense flexibility, but that comes at a cost of better communication about patterns and practices. The burden of keeping things organized is largely higher without OOP since OOP does enforce more rigid design constraints and they need satisfying as time goes on. That is often a good thing when delivering features wins over refactoring and cleanups.