>Wait—that last state doesn't make sense. With a real door, you can technically turn the key while it's open, but does that meaningfully change its state?
Yes, you can't close a door that is open but the lock is turned. So this state actually makes sense in the real world.
In fact, if you try to close a door that is locked, you’ll put a large dent in the door jamb. So this combination is not only sensical but desirable to detect.
Perhaps a better lesson is to not be overzealous when paring down your logical model.
> Yes, you can't close a door that is open but the lock is turned.
That depends. If it's a deadbolt, you're correct. If it's the lock in a doorknob, you probably can. This is typically how I lock my front door when I leave, I lock it then close it. Cars doors can also generally be locked then closed.
I thought the same thing. And now the "locked" enum state doesn't just mean locked, it means closed AND locked. And I don't actually like it when an enum value implies multiple things.
And by examining the model, we discovered a flaw in our understanding, that doors can lock open, which is maybe undesired or dangerous. So this model was successful.
But if the model doesn't reflect reality, then reality breaks the software. That's how bugs happen.
Which means that the non buggy model that best reflect reality, and covers all possible scenarios that will happen in production is the two boolean one, not the enum.
Which has its own unexpected bug in that the extended deadbolt can damage the wood frame and/or trim. Or perhaps the sensor you use to determine the door's state (open or closed) is positioned on the hinge side in such a way that it's triggered when the door is kept open with the deadlock extended. It's close enough to closed that the sensor gets triggered, and you--I can't help myself--open the door to the possibility that your system falsely represents the door as being both closed and locked.
This stuff can be hard, and sometimes, you just have to refactor later on instead of trying to nail down every possibility for the model, despite trying to figure out likely issues in the near-term. In which case, the goal is to keep in mind that data models will eventually change over time, and consider how that knowledge might change what you're writing now to make that process less painful.
> Which has its own unexpected bug in that the extended deadbolt can damage the wood frame and/or trim.
It doesn't. The data is correctly representing the state of the system. Your "bug" assumes a lot of things about the environment, any of which may or may not be true depending on the specifics where the system is running.
> Or perhaps the sensor you use to determine the door's state (open or closed) is positioned on the hinge side in such a way that it's triggered when the door is kept open with the deadlock extended.
Again, an implementation problem. The sensor was installed in a way that's incompatible with the underlying system. Can it be fixed by changing the data model? Unlikely. In fact, I don't think it can be fixed at all. If the sensor lies, there's nothing the underlying system or the data model can do about it, especially if it's a binary sensor like the one described.
If the deadbolt was installed in such a way that it never crossed into the door frame but rather only moved inside the actual door, would you consider it a bug in the lock, the deadbolt, or simply bad installation?
I like booleans, sometimes when I'm starting those nested if statements, I'll just go ahead and take the cases, enumerate all of the conditions in a "truth table" and write code accordingly for each case. The best thing about this is that you see all of the cases and can spot the undesirable or invalid cases and plan for them. Just like the article says, you spot an odd case (door locked but open) and can get a "heads up". The only thing is that the article seems to be against booleans so watch out for just enumerating the cases you expect because as mentioned, those "door locked but open" cases could actually be possible but unexpected.
And you need that state in the game Grim Fandango (spoiler) to solve a puzzle: lock an open door before the maintenance demon leaves. Then when he leaves he’ll close the door. But it won’t be close. So you can get inside.
Yes, because they are focused on the relevant parts for solving a specific problem.
So one could say that the article's fundamental flaw is not explaining what is the purpose of the model, therefore we cannot assess if it is capturing the relevant aspects to solve the problem.
>Wait—that last state doesn't make sense. With a real door, you can technically turn the key while it's open, but does that meaningfully change its state?
Yes, you can't close a door that is open but the lock is turned. So this state actually makes sense in the real world.