Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Nah, not at all.

It basically just means that you define states for your program to be in and you define from what state to what other state your program can go to under what conditions.

For example, let's say you have a program that takes user input and once everything is entered correctly, then you move on to the next thing.

That would mean you have a state "user_input" (or whatever you want to call it). Then you'd have a event "User clicks OK-button", with which you'd do a state transition. And then there's two possible state transitions, one which loops back onto user_input, for when the user enters something that's not correct, and one that points to the state of that next thing, with a condition of the user input being correct.

You could also directly specify here what "correct" user input looks like. That's your choice. It's a design tool, use it to whatever depth you need it.

There's a relatively intuitive notation standard, which you'll want to learn, as writing it all down is what gets you to actually think through all the states, events and conditions that there are.

Implementation-wise, you'll usually have a variable that holds your state and then methods to do state transitions. You can also implement a check into those methods to ensure you're in a state that's allowed to transition to the state that this method transitions to.

And even if you never end up using it, it is a nice mindset to get yourself into.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: