Basically I love object-oriented programming but the problem with the way OO evolved is that classes do "too many things".
Currently trying to move a fairly simple bit of code from one class to another, but it's actually very difficult because classes aren't just encapsulating data or functionality, they become sort of generic "scopes" that bundle together all the utilities a bit of code might need. And all those utilities remain in the original class.
@mcc stuffing everything in one class instead of creating a bunch of smaller logical units in a library that correctly abstract the thing the class was designed to do is the number one dark pattern in OO programming.
It's an architecture failure tho - you can absolutely write good libraries in OO languages. They often require at least one additional level of abstraction than you expect going in. (That adds cost up front even as it saves cost in the long run - which is why we get "god objects".)
@tess @mcc Older I get, more convinced I become that the "god object" anti-pattern is indicative of languages where the object-creation / management abstraction is too heavyweight.
To make one new Java class for general consumption, I don't just... Make a class. I create a file, and put that file in the right place, and declare its package membership, and create the class, and declare its members, and-and-and-and... IDEs help but it's still actually a lot of lines of code.
Whereas one new function in an existing class is way, way cheaper, and everything that already knows about that class now has access to it.
God objects are indicative, I think, that what the user wants is easy access to a *context,* either static or runtime, for which a class family and object instantiation are a poor substitute.
@mtomczak @tess This is a good observation. Kotlin makes this a lot easier, but Kotlin also fundamentally uses the same Android API that was originally designed for Java, so the problem is sort of baked in