We do go to the door and call door_open(DRIVER_SIDE) - it's just second nature now because we've done it so many times that it takes up no conscious bandwidth. But that subroutine is running somewhere in the brain.
To use a car, we're performing a bunch of actions involving modifying the state of a car. That seems to be quite analogous to the OOP way of thinking.
You're right that we don't consciously think of car travel in this way, but I don't see that as inconsistent with OOP either. Our thinking about cars is highly abstract, as though it's an abstract class/interface with a single go_somewhere(destination) method, which fits quite well with OOP thinking.
But the thing is that now the car has to know about the world.
If there's a wall on the driver side how can it open the door?
I'm not dogmatic on OOP vs FP, but let me take the side of FP here, we could model this as the car being a data structure with its position (x, y, etc), and a representation of what opening the door is (width of the car + length of the door, an anonymous function, or a named function, that can be made polymorphic) and now our open_door(car, world) can take both and the world doesn't need to know about what is a car and the car doesn't need to know about the world either, it just serves as a mapping, and the function open_door checks the positions of car in the world, transforms the car according to its procedure and checks it still fits the world and if not it produces an annoying beep.
> Our thinking about cars is highly abstract, as though it's an abstract class/interface with a single go_somewhere(destination) method, which fits quite well with OOP thinking.
So what you're saying is I'm going to have to downcast to a concrete class to figure out if my object is actually suitable for going to the store or my bathroom (my house isn't big enough to drive a car through).
Ideally the interface is named in a way that's self-documenting and makes it clear that it's not referring to moving around your house, no downcasting required.
To use a car, we're performing a bunch of actions involving modifying the state of a car. That seems to be quite analogous to the OOP way of thinking.
You're right that we don't consciously think of car travel in this way, but I don't see that as inconsistent with OOP either. Our thinking about cars is highly abstract, as though it's an abstract class/interface with a single go_somewhere(destination) method, which fits quite well with OOP thinking.