Back in 2015, Brian Will wrote a provocative blog post: Object-Oriented
Programming: A Disaster Story. He followed it up with a video called Object-Oriented Programming is Bad, which is much more
detailed. I recommend taking the time to watch the video, but here’s my one-paragraph summary:
The Platonic ideal of OOP is a sea of decoupled objects that send stateless messages to one another. No one
really makes software like that, and Brian points out that it doesn’t even make sense: objects need to know which
other objects to send messages to, and that means they need to hold references to one another. Most of the video
is about the pain that happens trying to couple objects for control flow, while pretending that they’re decoupled
Overall his ideas resonate with my own experiences of OOP: objects can be okay, but I’ve just never been
satisfied with object-orientation for modelling a program’s control flow, and trying to make code
“properly” object-oriented always seems to create layers of unneccessary complexity.
There’s one thing I don’t think he explains fully. He says outright that “encapsulation does not work”, but
follows it with the footnote “at fine-grained levels of code”, and goes on to acknowledge that objects can
sometimes work, and that encapsulation can be okay at the level of, say, a library or file. But he doesn’t
explain exactly why it sometimes works and sometimes doesn’t, and how/where to draw the line. Some people might
say that makes his “OOP is bad” claim flawed, but I think his point stands, and that the line can be drawn
between essential state and accidental state.