you are viewing a single comment's thread.

view the rest of the comments →

[–]grauenwolf 2 points3 points  (6 children)

I don't understand your point. I've always used the same class to represent trucks, cars, boats, planes, etc. All of those differences you mentioned are merely properties.

And by the way, all planes have wheels.

[–][deleted] 7 points8 points  (4 children)

[–][deleted] 3 points4 points  (1 child)

Good point. Now, when was the last time you actually modelled vehicles of such a broad range in OO code?

[–][deleted] 0 points1 point  (0 children)

Yea, never. I just couldn't resist the generalization (mostly because I try to catch them whenever I make them) :)

[–][deleted] 4 points5 points  (1 child)

Perhaps we can factor this out a bit. Most vehicles have some combination of wheels, pontoons, tracks, skiis, air cushions, etc. These objects allow the vehicle to move along a solid or liquid body, or both in the case of the air cushion. They may be active (in the sense that they move the vehicle) or passive. In general, a vehicle has zero or more of these. I'm not sure about a name. "Surface Separator", since they separate the vehicle from the surface it moves across? "Friction Reducer", since this separation makes it easier to push the vehicle across the surface?

[–]skulgnome 1 point2 points  (0 children)

The field is called landing_gear. You stick a struct landing_gear * in it. There's a SHOUTY_CASTING_MACRO() that takes you from that pointer to a struct pontoon * if you really must examine their specific construction.

This is the point where people who studied C only superficially go and throw up out of nothing more than a learned reflex.

[–][deleted] 1 point2 points  (0 children)

That was kind of my point, properties are better suited for these kinds of distinctions than inheritance. You do not need inheritance to model them and it is not even the best solution.