As soon as I stopped trying to write textbook OOP stuff, this stopped occurring to me. That was years ago.
I'm not saying I write perfect code, no. But when I read bad stuff I wrote, I can understand it and think of ideas about how to improve it if that becomes necessary.
On top of writing more functional-style code, the way I achieved this was:
Absolutely no inheritance whatsoever. Composition + interfaces work wonders for what I do.
Minimal mutable state. This pays dividends when debugging.
Ditto for type-system-encoded nullability markers (ie. ? in C#, std::optional in C++...)
I avoid writing code just-in-case something happens. If I haven't run it manually or via unit tests, it goes to the garbage bin (not an absolute, just a guiding principle). There's a chance that code isn't even correct to begin with and you'll have to throw it away should you ever need it.
Low indirection. I don't want to jump through 10 functions to see what something is doing, and nobody else does either.
The effort that goes into making this is not spent fixing bugs or adding features some care about (like HDR video for instancr, or a proper time picker?)
Ouch, for something as sensitive, I don't trust code reviews to catch vulnerabilities. They probably won't happen overnight, but I don't want to risk being a victim to the gradual laziness that comes with backseating programming over time.
Ouch, for something as sensitive, I don't trust code reviews to catch vulnerabilities. They probably won't happen overnight, but I don't want to risk being a victim to the gradual laziness that comes with backseating programming over time.
At that scale, contracts are multiple interfaces, not just one. And C#/Java /whathaveyou interfaces are largely irrelevant, we're talking way broader than this. Think protocol, like REST, RPC...
Wholeheartedly agree. OOP was supposed to offer guardrails that make it harder to write irremediably bad code. When you measure the outcomes in the wild, the opposite is true. Traditional OOP code with inheritance makes it hard to adapt code and to reuse it, as far I've been able to measure.
It works in huge teams where teams aren't closely integrated, for development velocity.
Defining a contract that a service upholds, and that dependents can write code against, with teams moving at will as long as the contract is fulfilled is valuable.
I'll grant you it is true that troubleshooting those systems is harder as a result. In the huge organization I was in, it was the job of a non-coder specialist even.
When a system uses words of a specific size, you need to use the same size for wraparound behaviour to work as expected. Incrementing 0xffff by one needs to return 0. It's easy if you use a uint16_t. Not so much if you use an unsigned of unspecified length.
Those are very powerful abstractions for sure, but did you notice how far their implementation is from standard Java OOP?
That's because polymorphism at a macro-level is a functional concern, not something programmers speak in conferences about.
One of my biggest gripe with Y2K-style OOP is that its proponents make lots of promises that don't track in practice when you measure the outcomes. One such promise is that writing rigid class hierarchies lead to the potent abstractions you describe.
Not just you, bud. We've seen the science confirm that the supposed productivity increases are a mirage.