But OOP was specifically created to model real world objects and their relationships. If this article is saying OOP doesn't do that very well and we should not think in those terms, what's it good for?
Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
81–90 of 177 posts
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#82I 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…
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…
Just thinking here, but what if you take the guesswork out of it "Here at Company X our philosophy is to avoid deep class hierarchies. How would you model..."
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#83As 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.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#84I do scientific modeling. We have classes and hierarchies of different physical components we simulate, like fuel assemblies and pumps and heat exchangers. I guess this falls into the exception of "clone of The Sims or something" so perhaps my complaint is covered.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#85I do scientific modeling. We have classes and hierarchies of different physical components we simulate, like fuel assemblies and pumps and heat exchangers. I guess this falls into the exception of "clone of The Sims or something" so perhaps my complaint is covered.
Yep, me too. I guess most programmers dont know what modelica is or does.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#86The problem is “A extends B”. You want to teach “A implements B” first. The important idea is that there’s a protocol/interface for which there can be different implementations used in parallel at runtime, and the interface type allows the client code to abstract from the different implementations. The next step is that an implementation may implement multiple interfaces at once, which also may be subinterfaces of one another. Only as a last step you can introduce implementation inheritance, which is just an optimization (both in runtime mechanism and code verbosity) when reusing code, an optimization which comes at a cost regarding maintenance and implementation dependencies.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#87Earlier quoted context omitted.
Not every person in the interview process is anywhere near you in the org though, sometimes great jobs are behind a shitty interview
Yes, and sometimes shitty jobs are behind great people. Candidates get catfished in interviews all the time.
In my experience there are few great jobs behind shitty people. Great jobs tend to not put shitty people in the hiring loop.
Similar works backwards, if you're using the interview to also ask the right questions, good people are generally not going to lie to you...
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#88I 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 `Duck / Cat / Dog That's not the point. A beginner knows what a dog and a duck and a cat are in the real world. The "a-ha!" moment is mapping real-world relationships into a brand new abstract environment called Object Oriented Programming.
When you've never written a line of code in your life, abstract things like "network protocols" and "file I/O" and "ImageDisplay" (which is neither an image nor a display) are confusing, and so frustrating, and so not useful for teaching a complete novice.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#89After 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 can lead to overly complex code, uneeeded abstractions and design patterns thrown on top of each other for no good reason.
All programming paradigms can do that, you are not making any particularly salient point about OOP here.
OOP doesn't mean that everything needs to be an object, but inheritance and shared behaviors are concepts that map neatly between the real world and the programming world, which is why OOP has been such a resounding success.
We have refined this approach now (e.g. using delegation over inheritance), but these basic concepts of shared behavior and reuse remain.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#90After 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 beyond the most common thing I miss.