Man, this really is the crux of it for me: when the focal point is a series of opaque state mutations, there are exponentially more ways to do those steps in the wrong order than the right order. And the contracts for those methods have absolutely zilch to say about what they assume has already happened or will happen after they're called. You just have to know (or hope somebody wrote it down in English). This is my biggest pain point/source of anxiety when working in an OOP codebase.

And then guess what? Suddenly you're extremely concerned with the internal state of those objects. Because understanding it is essential if you want to have any hope of actually using them. And the great irony is that this completely undermines one of the main benefits of OOP: private state that the outside world doesn't have to care about.

> did not call putFeetInCar before adding driver

> did not call putShoesOnFeet before calling putFeetInCar

That's bad architecture, not an OOP flaw. These should've been private methods called and error-handled properly from driver.prepareForDriving, or even implemented as a DriverPreparedForDriving subtype.

> did not set up HandKeyAllocatorManager or use KeyDashboardMeldConnector to insert key into KeyHoleDoodadInterfaceXConnector

All these sound like bad OOP (or Java) to me, a HandKeyAllocatorManager is not a thing in the domain. I'd rather build my logic around objects like HandsContents, KeyKeyholeCompatibility or SeatedDriver.

I’ve decided to assume this is perfect satire and have upvoted it accordingly.

It's not supposed to be, what made you think that?