Real-world objects don't have this property -- it would be like the gas tank hatch disappearing from my car after I fill it up, and reappearing once I drive around for a minute.
Some do. When the gear shift lever on my Mazda is in one of the automatic slots, you can't upshift or downshift manually.
In business this is even more obvious. Contracts might have states: proposed, drafted, agreed, signed, and so forth. You can't sign a draft, it has no meaning. That's part of the business process.
In the software case you explained, the interface changes so you can't even try to do the wrong thing. On real-world objects, you can always try to do the wrong thing, it just doesn't work.
Henderson replies back on the squack box: "Sorry sir, it's still a draft, it has to be approved by legal before you can sign it."
> Your Mazda shift lever's manual slot doesn't disappear when you're in automatic
No it doesn't, but you can't actually move the lever there without changing the gearbox's state from Drive to Manual.
So, we can say that it has an interface including the messages "+" and "-" at all times (The slot), but there's no way to send it a "+" or a "-" message unless the gearbox state is "M."
The entire point I was making in the article was that OOP is a terrible model for the real world. This is at odds with the claim made that the universe decomposes politely into objects and that OOP is a natural fit for modeling tasks.
I think an important thing to remember is that sometimes we don't want paradigms that correspond precisely to the real world. Airplanes didn't become a practical reality until we stopped trying to mimic the flapping actions of birds.
The suggestion of having a state machine driving the availability of actions seems tangential to the modeling task, and is instead related to correctness. Personally, I would take correctness over closeness-to-reality every time in modeling terms.