4 ms·

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 de

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.

xbfjvusb6 4y ago
I find OOP fine but it's not something you can just let rot. You need to be ok with redefining classes and refactoring things around the new boundary lines regularly as requirements change. 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.
- PainfullyNormal 4y ago
  Your post reminds me of this scene from Indiana Jones and the Last Crusade: https://www.youtube.com/watch?v=nGTEXqudVJM https://www.youtube.com/watch?v=nGTEXqudVJM
int0x2e 4y ago
I often feel the same way. I've seen cases where trying to add functionality to an existing but "very clean and correct" codebase ended up being extremely difficult and the result felt far too complex in my mind. 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.
ChrisMarshallNY 4y ago
OOP, when done badly, is an eight-gauge footgun. 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.
- PainfullyNormal 4y ago
  There is such a thing as a bad tool. In most industries, they simply refuse to use the tool anymore. Not so much in software development, for some reason.
- yakshaving_jgt 4y ago
  A good tool drives the wielder towards success. 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.
  - ChrisMarshallNY 4y ago
    Define "good." 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.

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.

xbfjvusb6 4y ago

I find OOP fine but it's not something you can just let rot. You need to be ok with redefining classes and refactoring things around the new boundary lines regularly as requirements change. 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.

PainfullyNormal 4y ago
Your post reminds me of this scene from Indiana Jones and the Last Crusade: https://www.youtube.com/watch?v=nGTEXqudVJM https://www.youtube.com/watch?v=nGTEXqudVJM

int0x2e 4y ago

I often feel the same way. I've seen cases where trying to add functionality to an existing but "very clean and correct" codebase ended up being extremely difficult and the result felt far too complex in my mind. 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.

ChrisMarshallNY 4y ago

OOP, when done badly, is an eight-gauge footgun. 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.

PainfullyNormal 4y ago
There is such a thing as a bad tool. In most industries, they simply refuse to use the tool anymore. Not so much in software development, for some reason.
yakshaving_jgt 4y ago
A good tool drives the wielder towards success. 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.
- ChrisMarshallNY 4y ago
  Define "good." 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.