Translations:中文
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 by design.
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.
