Case against OOP is understated, not overstated (2020)

Re:Case against OOP is understated, not overstated (2020) by rosenjcb on Thursday February 10, 2022 @06:45PM (#30294535)

Elegant Objects by Yegor Bugayenko actually argues against mutation in OOP for the same reasons that FP advocates due (bad for concurrency, hard to test, hidden state is hard to keep in your head, et cetera), but then all you get are namespaces with functions that act on a (usually) single data type (i.e. the class itself and its properties).

OOP itself could be good for problems where you need state machines. The Erlang Actor model is successful for a reason, but I wouldn't apply OTP to general programming.

[ Parent | on HN ]

Re:Case against OOP is understated, not overstated (2020) by pishpash on Thursday February 10, 2022 @07:53PM (#30295313)

Nothing that the typical junior engineer does with OOP can't be done with functions and well organized files. If they can't be trusted to do that well they shouldn't be writing OOP code.

[ Parent | on HN ]

Re:Case against OOP is understated, not overstated (2020) by mypalmike on Thursday February 10, 2022 @08:45PM (#30295733)

When everything's a function, junior programmers treat the entire set of available functions as reasonable things to call at any time. With OO, they at least have to think about how to organize things by which interfaces are available.

People love to hate on Java, but a Spring app with everything set up into a graph of interacting interfaces is about the most well-organized code you'll ever see, and it encourages modifications that maintain thoughtful organization.

[ Parent | on HN ]