91–100 of 177 posts
Inheritance in OOP languages is used to either for interfaces, or for tacking on data and maybe functionality because you are too lazy to implement out composition instead.
As someone who has been using OOP since C++ was Cfront and you fetched it from usenet ... I find these conversations fascinating. It's like listening to a conversation about cars where someone says they hate cars because you have to figure out a manual choke and the many inner tube failures. Do people still use these crazy inheritance trees? I haven't encountered it since the early 2000's.
> In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus I wish someone had told me this when I first started coding. I wasted so much time building pointless hierarchies based on ontology rather than DRY.
The thing about the natural world is that “Nature does not practice OOP.” Our nice hierarchies of animals reflect our desire to build hierarchies. Those hierarchies are tools that are useful for many purposes, but they weren’t blueprints for constructing life. I speculate that if we think of our hierarchies as tools, they say at least as much about our own brains and the problems we’re trying to solve as the do about…
After many years of OOP, I'm not sure if we gained anything from OOP, and if it wasn't a solution in search for a problem. At first I was enthusiastic. Then I've realized that there might be better ways to solve problems than trying to fit everything in a "everything is an object" mentality. OOP can lead to overly complex code, uneeeded abstractions and design patterns thrown on top of each other for no good reason.…
OOP still rules the GUI. Even if you spread some functional sauce all over it.
> In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus I wish someone had told me this when I first started coding. I wasted so much time building pointless hierarchies based on ontology rather than DRY.
The real art is maintaining the balance between abstraction and pragmatic simple code.
I disagree with the article, which talks about building a holistic understanding when learning, and then ironically misses the forest for the trees regarding programming metaphors. The author is obviously an experienced programmer, so I suspect they've forgotten what the mindset of an absolute novice is like, and to start programming with zero prior exposure to the concepts. For the novice being introduced OOP, the `…
Don’t worry about Wimp Lo, he’s an idiot. We’ve purposefully taught him wrong… as a joke.
Composition is an infinitely better method to teach if you have to teach OOP. That way you don’t need to unlearn what you thought was the right way but is actually useless at modeling almost anything.
I actually like to ask people in interviews to model a car and car factory because I want to see right away if they go deep into the nonsense of extending everything, or if they can use composition, or get away with something focused on maintainable code that meets requirements. I've seen it all. Prius extends Car extends vehicle extends motor extends ... Right within the first five minutes of the interview. But I al…
"Car/Animal extends..." slowed my ability to comprehend OOP significantly when I was learning to code. It just did not make any sense to me and I felt like an idiot for not being able to equate these "real-world" examples to the code I was trying to write. I just could not make the connection. It wasn't until I started trying to make a simple video game that these concepts made sense: an "Enemy" class could have prop…
Yeah. Exactly. Which is why Dog extends Animal. It has a set of common features (code/behaviors, and data like number of legs, amount of fur, and so on). It is a really good analogy and a really good point to give someone an idea of why you would use inheritance. It requires absolutely no programming knowledge, and best of all, it's not difficult to imagine cases where you might actually use it. c.f. basically any game with dogs in it where they're a subclass of NPCs.
And the same for Car extends Vehicle. A vehicle can have any number of wheels and any number of doors. A car can have any number of doors but it always has 4 wheels. All cars move in approximately the same way, while vehicles can articulate or skid-steer or ...
Just because something is simplified does not mean it has no value. And just because *you* would not use these designs in *your* life does not mean others wouldn't. As TFA says: "unless they are talking about writing a clone of The Sims".
After many years of OOP, I'm not sure if we gained anything from OOP, and if it wasn't a solution in search for a problem. At first I was enthusiastic. Then I've realized that there might be better ways to solve problems than trying to fit everything in a "everything is an object" mentality. OOP can lead to overly complex code, uneeeded abstractions and design patterns thrown on top of each other for no good reason.…
I just wrote 60k lines of C code and have never once felt the need for OOP. And I say that as someone who has spent their whole career with OOP. If I need some functionality, I write a function and pass it a struct. I’ve yet to find a time when this approach is too limiting, or chaotic. Even for interfaces, function pointers achieve that goal entirely. I do miss type safe vectors, e.g templating. Thats above and beyo…
Earlier quoted context omitted.
In job interviews, people don't write the code they would write normally, they write the code that they think the interviewer wants to see. And that brings me to a topic that's entirely different but also very relevant: job interviews bring interviewer-biases with them. If you run into an old-school interviewer who would do exactly that "Prius extends Car extends Vehicle, etc." nonsense, but you don't know it, they w…
Every example you listed would be dodging an enormous bullet. The exact example the grandparent used was essentially a wrong answer, so our "old-school interviewer" (that sounds kind of ageist doesn't it?) marking us down for not using it is a bad thing. An interviewer who loves functional programming and doesn't communicate any preference then marks you down for not reading their mind is someone to avoid. An intervi…