Much better to use something like Person and Employee/Student, where it's easy to immediately grasp the value based on not having to duplicate the data fields you'd need for a basic CRM. (As opposed to having to make up ridiculous methods about the panda eating bamboo or whatever where no one understands what the fuck is going on.)
The purpose of functions only started making sense after learning calculus and the replacement method, where a complex term was replaced by a single variable. This is where I learned they're mostly for readability, an adaptation to make programming easier for humans to do.
Essentially my gripe with the animal and car analogies is exactly what Alex3917 wrote above - you're (almost?) never going to actually implement anything like a car on an animal in a real program. And if you do, you're almost certainly not going to give it methods like 'Honk' and 'Meow' (which is exactly how OOP was described in my first class on the subject.) It's not that they're bad analogies - in fact it's almost that they're too good of analogies. They represent the OOP concepts very well, just not the practical usage of the concepts.
Actually the truth is I'm a little bit disillusioned with OOP altogether, and it seems like there's a lot of movement in the industry away from OOP with things like Go, Rust and other more purely functional languages.
Did you mean "on" or "or"?
Using OOP to implement a vehicle is a no-brainer. It's a completely standard model for games.
Extending the animal class to make a car would be weird though.
One point of OOP isn't that you make classes, but that the classes you make can be easily duplicated and automated.
So you can make an animal with a few simple behaviours, use your animal prototype to make a herd or flock, and suddenly you've got emergent semi-intelligence, which you can define by changing a few lines in the prototype.
It's not just a way of giving properties to something that's kind of like a real object - it's a way of simplifying automation and bulk updates of related entities.
