This is a mind-blowing and cool idea as others have said, but the idea of an object whose methods change depending on their internal state is a bit counter-intuitive.
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.
Not quite the same. Your Mazda shift lever's manual slot doesn't disappear when you're in automatic. You can still sign a draft contract, it's just not binding.
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.
You cannot sign a draft, signing is a legal thing, not just a putting your name on a piece of paper thing. Imagine you're a manager and you call your EA: "Henderson, get me the YC contract to sign!"
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."
> 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.
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.
I think it's only counter-intuitive because it doesn't yet exist as a common programming paradigm. Once it does the error message should be no more confusing than average--harder to find than null exception, but easier than inspecting a core dump.
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.