Object Oriented isn't Good
Object Oriented Programming isn’t Good
Object Oriented Programming (OOP) adds more complexity and doesn’t help in making good software, instead:
- OOP asserts a working model
- OOP is popular
- OOP is non-falsifiable
And this means it’s less of a tool and more of a style. Styles are cultural and serve different purposes than pure efficiency or producing quality. This style of OOP imitates consistency, but nothing more.
Instead of arguing intangibles, and belaboring that OOP’s popularity doesn’t prove or disprove its utility, I’ll lay out more tangible and verifiable qualities of OOP that I’ve collected.
Language
OOP is tightly-coupled with language. Currently, whenever it’s brought up (2026) it’s often stated that it “originally meant Smalltalk.” I’m sure this has helped many conversations, and deepened our understanding of what OOP is. (that is sarcasm)
Modern languages influenced by OOP design are
- JavaScript
- Python
- Rust (yes even Rust)
- C#
- Java
- C++
I pulled this list from the
StackOverflow developer survey 2023,
and skipped those without class definitions.
[http://wiki.c2.com/?DefinitionsForOo]
A lot of these languages are pretty good, but more and more, I find myself not using the OOP “goodness”
My Critique
Most of these are all going to be my opinion. I feel like that’s probably good enough since it seems like most OOP apologists have the same level of evidence that OOP is good.
Name Games
OOP confusions often boil down to a name game. “If I had a chess object and I needed to add pieces to it, which accessor method should take a generator template,” and other rhetorical nonsense. Sure, it’s fun to make up a new language able to describe how things might behave. The most fun thing is software that works and works well, and when you’re maintaining it you can fix it. I’m not sure OOP people ever experience this thing, since they seem to talk incessantly about structures and abstractions.
OOP doesn’t help designing software that works and works well. If it did because of its attributes as a practice, then no other philosophy would produce software of similar (or often better) quality. On a empirical basis, this is no surprise: all programming paradigms are identical (thanks Turing).
I’m sure some problems are better handled by an obsession with hierarchy. I’m sure that some will find it easier to think of your code as a structure that imitates some real-life system. But even there, OOP is bizzare.
Real objects don’t have methods that other objects can call. Real objects often defy strict classification - and humans with the knowledge and nuance of actually existing in reality are able to cope with it without constructing bizzare name games.
Does the tree “belong” to the ground because its roots are in it? Does a cat and dog belong to an “Animal” class with an “is-a” relationship?
It’s ridiculous.
And yes, the examples that are used to teach OOP suck too: doing “dog and cat is-a Animal,” helps nobody. But at the end of the day, that’s still what OOP is. It’s just bundling crap together. Which any programming paradigm can do.
It’s easy to avoid this: just don’t do any inheritance, make a bespoke class for everything. Or better yet, don’t use OOP.
Imeasurability
OOP is not measurable, or quantifiable, and it’s benefits are that it is used. There is a presupposition that OOP is actually useful - why wouldn’t it be, we’ve written books, made derivative practices that “solve” things caused by the thing that was obviously so great. 4 billion computers use OOP, are you better than 4 billion of anything? 4 dudes wrote a whole book on how to not do it bad (since it’s so easy to mess up such a good system.)
There’s not really a measurable way to evaluate OOP: “Readability,” “ease of use,” “understandability” are all so wishy-washy that people will shill their own solution absent any need just to satisfy these “-ilities” that have sprung from the good idea fount of their choice.
OOP proponents might also bring up, “well actually, it’s good for UI,” but I am not even convinced of that. In React, the most popular ECMAScript UI engine on the web today, they ditched the useless OOP trash to go with the functional system.
Sure, QT was popular; today most people seem to make apps using Electron and I Dare to guess that no one misses having to make Objects to handle stuff like Java fanboys might thing.
It’s easier
No, and Go proved this.
Java proponents praise that every java program looks the same. Yes, that’s nice; it’s actually great that you can mess with java programs without knowing what you’re doing. How else would java programmers get anything done!
Joking aside, the most aggravating miss in all of software is that every C++ program looks like nothing you’ve ever seen before. It is beyond frustrating that whenever you open a C++ file that hasn’t been seen in a while no one will be able to read it (this isn’t always true; see certified software, if you dare). It’s even worse for Prolog, but I think we all hated it. I look back at my own C and C++, and I’m convinced that the way the language works is why there are adages about psychopaths reading your code are spouted by people selling books. By the way, Robert, it’s not good.
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live
https://sercankulcu.github.io/posts/2025/02/clean-code-psychopath/
One thing I give credit to Java, is making this (apparently) tenuous relationship with the people you presumably work with a non-issue.
But Go does it so much better.
Go’s philosophy of “one way to do it” is the better way, and you might notice they dropped classes and inheritance. No Monkey, Banana, Forrest shenanigans here.
All your hierarchies are bunk
I’m going to dunk on every OOP practitioner who tells the fable of “You want Animal Objects so you don’t have to code more.”
They are wrong.
The tale goes you start with a cat, and you need to “extend” your (useless) program to cows, dogs, and unicorns. Before any OOP apologists say “it’s not real”
behold my receipts:
What happens every time is that you end up having to write more code for the actual useful data that needs to eventually be written. And then you have to tape and glue and weld around that perfect structure you love so much
By the way, the reason I call you apologists is because, just like religious apologists you have to dance around your own history. The Animal example is the first example anyone teaches about inheritance. Bertrand Meyer might as well have written the Bible to OOP, and most OOP adherents probably have not read it. He spends most of the Inheritance chapter explaining how inheritance sucks, and points out that the Animal inheritance has known flaws.
Why we didn’t just go with traits, I’ll never know. I guess we were too busy
writing our third MonkeyBannannaForrestFactory.
Topology mismatch
How many problems are trees?
How would you design a Spreadsheet using OOP; well you really wouldn’t it’s pretty simple. Each cell being its own object is a bit.. overkill?
OOP isn’t a Golden Hammer, but it is a Hammer and people love it for some reason
Queue the anti-OOP programming; it’s not a good thing, and it doesn’t solve anything. I say this not advocating per-se for the functional approach, nor imperative, nor Rust - though you should consider writing it in Rust.
What I will say, is that it can sometimes be super useful. When it is (or when I think it is) I always do a double-take;
- Don’t use inheritance; maybe it’s easier to do a modification in-place?
- Ok if it’s not, maybe there’s a shared underlying structure
- Ok, if I do use inheritance how painful will it be to rip this apart
- Ok: it’s actually time to use inheritance
That’s how I do my thought process: if at any point I say “actually it’s better to do something else,” I drop the old thing immediately. Even then, you often can’t tell if you’ve made a mistake until after you see the consequences of your decisions.
But these days, I don’t want to reach for any OOP approach by default. I don’t want to build towers of constructed structure. I don’t want to have to inject my dependencies and not know how the system might function.
OOP is a tool for someone who is far less curious and less involved than me.