250bpm

I can't wait for the next post :-) ! Are their any studies that confirm: "events + state machines > others" ? Thx again !

Excellent article!

An excellent article. I am definitely gonna use those ideas for my projects.

Anyway, I was fed up with doing the same stuff all the time, so I wrote go-statemachine. I am going to use it for implementing objects that are supposed to act as small synchronous event loops, and that is basically what those state machines are, right? Feel free to comment on the library, it's not like written according to this article or super optimized, it is for my purposes. But I still think that it might be useful for someone. I wrote it like today, so it can and will change, but you know, it's there ;-)

Regards,
Ondra Kupka

Good article.

I think events are superior for several reasons:
1. They can be pretty easily logged. In your event dispatch simply log each event with its receiver.
2. They can have aspect-like rules attached. For instance: Any event which starts with 'set' should check the user who created it for authorization.
3. They can handle delegation by forwarding events to other objects. This is great for avoiding unnecessary inheritance.
4. Composition of events. Chain multiple events to fire in sequence.

Excellent reading, kudos! :-)

Event driven architectures and state machines are great to have in your toolbox, and this is a pretty good introduction to them, but I think your explanation of state machines does them a disservice.

Although the typical implementation is a bit less formal, these kinds of state machines *are* related to the finite state machines of automata theory, and that's a *good* thing. Formalizing things, at least to some degree, helps you think about them in a structured and well-understood way. That's because they're based on simple theoretical constructs, not in spite of it.

Any ETA for the follow-up article? Can't wait for it :-)

This is a pretty fantastic read. I've actually stumbled in this direction completely by accident when doing WinForms programming in .NET. I simply have sought out the simplest thing that could possibly work, and it ends out almost identical to your tree structure, where there is a main controller object that communicates via function call to its subordinates, who in turn raise events when something "interesting" happens.

All of the code that I see that fails to follow this pattern ends out a tangled mess of uh… "logic". It's never really clear who is doing what or responsible for this or that.

Excellent article.
That is exactly what we used (EDA and finite state machines) to manage the behavior of a robot.

Fantastic article. I have used event driven state machines extensively in the past and found it to be a fantastically easy system for creating logical flows through the system. You call them narratives and think that that is entirely accurate. You can understand the story of what happened by the events that arrive and knowledge of the states of the machines when that event arrived.