OOP is shifting between domains, not disappearing. I think that's usually a bad thing.
2025-11-18
Many bytes have been spilled on the topic of object-oriented programming: What is it? Why is it? Is it good? I’m not sure I have the answers to these questions, but I have observed an interesting trend that I think has flown under the radar: OOP is not disappearing, but shifting across domains.
Some quick and entirely incorrect history
In times of old, people wrote programs. Things were easy and simple. Then, a manager that didn’t know how much trouble they were getting themselves into asked two programmers to work on the same program. Bad things happened.
Some bright spark realised that bugs often appeared at the intersection of software functionality, and that it might be a sensible idea to perform a bit of invasive surgery and separate those functions with an interface: an at-least-vaguely specified contract describing the behaviour the two functions might expect from one-another.
Other bright sparks jumped in on the action: what if this separation did not rely on the personal hygiene of the programmers - something that should always be called into question for public health reasons - and was instead enforced by the language? Components might hide their implementation by default and communicate only though a set of public functions, and the language might reject programs that tried to skip around these barricades. How quaint.
Nowadays, we have a myriad of terms for these concepts, and others which followed in an attempt to further propagate the core idea: encapsulation, inheritance, polymorphism. All have the goal of attenuation the information that might travel between components by force. This core idea isn’t unique to OOP, of course, but it is OOP that champions it and flies its coat of arms into battle with fervour.
Programs-as-classes
At around the same time, some bright spark realised that programmers - a population of people not known for good hygiene - might also not produce the most hygienic of programs, and that it was perhaps important not to trust all of the little doo-dahs that ran on your computer. And so the process boundary was born, and operating systems morphed from friendly personal assistants with the goal of doing the dirty work of programs into childminders, whose work mainly consisted of ensuring that those within their care did not accidentally feed one-another snails or paperclips.
In tandem, other bright sparks were discovering that computers could be made to talk to one-another, and that perhaps this might be useful. Now, programs written by people that didn’t even know one-another - let alone trust one-another - could start interacting.
When trust dissolves, societies tends to overzealously establish the highest and thickest walls they can, no matter the cost. Software developers are no different. When every program has evolved into a whirlwind of components created by an army of developers that rarely know of their software’s inclusion, much less communicate about it, then the only reasonable reaction is maximum distrust.
And so, the process/network boundary naturally became that highest and thickest wall - just in time for it to replace the now-ageing philosophy of object-oriented programming.
Was it worth it?
Our world today is one of microservices, of dockers, of clusters, of ‘scaling’. The great irony is that for all of the OOP-scepticism you’ll hear when whispering of Java to a colleague, we have replaced it with a behemoth with precisely the same flaws - but magnified tenfold. OpenAPI schemas replace type-checkers, docker compose replaces service factories, Kubernetes replaces the event loop. Every call across components acrues failure modes, requires a slow march through (de)serialisation libraries, a long trek through the kernel’s scheduler. A TLB cache invalidation here, a socket poll there. Perhaps a sneaky HTTP request to localhost for desert.
I am not convinced by the promises of OOP, but I am even less convinced by the weasel words of that which has replaced it.