CODEWITHSUNDEEP
modelingstate-machine
m33lky
m33lky

Reputation: 7295

state machine modeling for pm

Let's say we have an FSM for a private message. Let's take a look what happens when it enters the state delivered. What do you think of the following approaches or is there a different one?

  1. Have 3 states: delivered, unread and read. Move automatically to the state unread.
  2. Have 2 states: delivered and read. Stay in the state delivered and assume that it's unread. Move to state read when necessary.

Comments:

  1. Is that a good idea? It makes the state delivered seem superfluous.
  2. At first it seems that we've saved a state. Imagine if we provide functionality "mark as unread". Should we move from read back to delivered? This seems a little counter-intuitive from a developer's perspective.

Upvotes: 0

Views: 62

Answers (1)

The Beruriah Incident
The Beruriah Incident

Reputation: 3257

Noting that you automatically move out of delivered, you're correct that that state is superfluous. Therefore, it's easy to optimize a meaningless state out. After all, delivered just means that you're in this FSM at all.

If you have a read message, and you mark it as unread, just move it back to unread. That's what the button means, and you can treat it intuitively. So, just simplify your system to two states (a single bit).

Upvotes: 0

Related Questions