Part of writing it "the right way" is to make it easy to change. This is why I've come to dislike OOP. The rules are too rigid and result in exactly what you describe.
I've come to think the real sin is coupling. If you try to keep your codebase clean at all times but don't refractor often enough, you end up with coupling where it shouldn't be, which can sometimes be a lot worse than some of the so called "deadly sins" such as code duplication.
This requires a testing suite that gives you confidence to make these sweeping changes quickly. Without it, it's not a fun way to work.
Also, you don't have to go all in on oop. I like to use procedural most of the time only defing objects for things I find more easy to reason about as objects.
For example, I'll write the command line interface in procedural that looks a lot like a complicated bash script and then define objects that do the work. This often results in objects not really changing much because they're not defined until later in development when their needs are well known. The place that changes is usually feature switches, command toggles, output formats, and the like. All that can be objects if you want but for the most part a function or two goes a long way and results in easier to change code.
I should know, I've blown off most of my toes.
But, you know what they say:
"Good judgment comes from experience. Experience comes from bad judgment."
I have pretty good judgment, these days (see "toes," above).
Well-written OOP, on the other hand, is a marvel of Quality, simplicity, maintainability, performance, and refactorability.
We often like to blame a tool, when it's really PEBCAK.
It's like we go to a bar, one night, and there's this old blues guy, alone, with a beat-up Telly and an old Peavey amp, making music that sounds like it came straight from God's House Band. It looks effortless.
So we rush home, buy a PRS guitar, and a Mesa Boogie amp, strike a pose, and hit the strings.
The cat grabs his favorite dead rat, and heads for the hills, never to be seen again.
The kids delete their TikToks.
The wife calls a lawyer.
Maybe there's something to be said for learning mastery of a tool, before disparaging it.
Given how frequently I hear something along the lines of "OOP is great; you're just doing it wrong!", I'm inclined to believe it actually isn't so great.
I hear functional programming is great.
Not so sure I'd write a driver with it, though.
Everyone loves to rain hate on C++. I ran a C++ shop for 25 years, and have heard it all.
Listen. It's current fashion to hate OOP, and I'll never convince anyone otherwise, so I'll just back off, and let y'all think what you will.
For me, I like some of the new stuff. If you you look at the links in my comment elsewhere in this thread, you'll see some of the transitions that I've made, from an older, OOP/delegate-based model, to one that leverages protocols and closures. I'm not averse at all to learning new tech, but I've found a lot of mileage in combining it with classic patterns.
Why not?
You see, I am not an expert functional programmer. I already know that it won't work well, for the UI-based stuff that I do, and, in my experience, UI programming, and device control programming, share a lot of patterns. But that may also be, because I am not actually in a position to render much judgment on the matter.
But, like I said. I am not an expert on FC. I have liked using some of its contributions to my favorite language (Swift), but that doesn't really give me the authority to make any really big statements on the pattern (like, for instance, "FC is bad for drivers").
See how it feels, when people throw shade on something that you know well?
My feeling is mostly that of confusion. I spent several years writing OOP, and then learned pure FP, and now that's all I do. Pure FP is the best thing I have ever used for UI programming.
My confusion is not from you "throwing shade" on something I know well. Rather, it's from you throwing shade on something you — by your own admission — are not in "a position to render much judgement".
> "I hear functional programming is great. Not so sure I'd write a driver with it, though."
That's not an insult.
Your comment wasn't, either -technically, but it wasn't quite as nuanced. It said that OOP was, by inference, a bad thing.
> "Given how frequently I hear something along the lines of "OOP is great; you're just doing it wrong!", I'm inclined to believe it actually isn't so great."
Like I said, this has descended to a religious debate, and I won't play, anymore.
But this is a big world, and there's many different things going on. I know that I'm an old "OK boomer," but I have also been writing ship software for over thirty-five years, so there's a vanishingly small chance, that I may actually have some valid points to make.