4 ms·

> We make class hierarchies in order to simplify the code by allowing different parts of it to be changed independently of each other, and to eliminate duplicat

by bighuh 4y ago

> We make class hierarchies in order to simplify the code by allowing different parts of it to be changed independently of each other, and to eliminate duplication (which comes to the same thing). 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".

jzwinck 4y ago
Here are a car and a motorcycle each with three wheels: https://en.m.wikipedia.org/wiki/Reliant_Robin https://en.m.wikipedia.org/wiki/Reliant_Robin https://en.m.wikipedia.org/wiki/Piaggio_MP3 https://en.m.wikipedia.org/wiki/Piaggio_MP3 What shall we do with them in our class hierarchy?
lelandbatey 4y ago
> A vehicle can have any number of wheels and any number of doors. Does that mean zero doors and zero wheels? Because a jet ski is surely a vehicle, right, and it has zero wheels and zero doors. Likewise, what about a cable car (aerial lift)? It has doors (maybe), but probably not an internal engine. It's definitely a vehicle, but it has almost nothing that's similar about it compared to the car (automobile) you described earlier. If it where a class, the "vehicle class" could really only meaningfully have some attributes related to transport (like human/cargo capacity) and some methods around movement in the most general sense. If we keep breaking this down, we'll find a huge taxonomical network, a vast sea of interlocking Venn-diagrams of attributes and capabilities. This is the corner that those OOP tutorials force people into: trying to turn a network into a tree, and it doesn't ever really work (at least not without awkward compromises). Sure, for a beginner who's never grappled with trying to map concepts to things, this can be a nice contained way to start. Eventually though, that beginner will need to learn some the next levels of more general thinking; e.g. one where they can start modeling interfaces/protocols and their relationships.
czx4f4bd 4y ago
> 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. Except even in game design it's a bad idea once you get more than a handful of entity types. https://gameprogrammingpatterns.com/type-object.html https://gameprogrammingpatterns.com/type-object.html

by bighuh 4y ago

jzwinck 4y ago

Here are a car and a motorcycle each with three wheels: https://en.m.wikipedia.org/wiki/Reliant_Robin https://en.m.wikipedia.org/wiki/Reliant_Robin https://en.m.wikipedia.org/wiki/Piaggio_MP3 https://en.m.wikipedia.org/wiki/Piaggio_MP3 What shall we do with them in our class hierarchy?

lelandbatey 4y ago

> A vehicle can have any number of wheels and any number of doors. Does that mean zero doors and zero wheels? Because a jet ski is surely a vehicle, right, and it has zero wheels and zero doors. Likewise, what about a cable car (aerial lift)? It has doors (maybe), but probably not an internal engine. It's definitely a vehicle, but it has almost nothing that's similar about it compared to the car (automobile) you described earlier. If it where a class, the "vehicle class" could really only meaningfully have some attributes related to transport (like human/cargo capacity) and some methods around movement in the most general sense. If we keep breaking this down, we'll find a huge taxonomical network, a vast sea of interlocking Venn-diagrams of attributes and capabilities. This is the corner that those OOP tutorials force people into: trying to turn a network into a tree, and it doesn't ever really work (at least not without awkward compromises). Sure, for a beginner who's never grappled with trying to map concepts to things, this can be a nice contained way to start. Eventually though, that beginner will need to learn some the next levels of more general thinking; e.g. one where they can start modeling interfaces/protocols and their relationships.

czx4f4bd 4y ago

> 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. Except even in game design it's a bad idea once you get more than a handful of entity types. https://gameprogrammingpatterns.com/type-object.html https://gameprogrammingpatterns.com/type-object.html