🎥 A video for this lesson is available.

This is an architectural lesson. It is more useful if you want to have multiple instances of the same state machine.

If you only have a single instance of a state machine, you can continue to use the global functions approach and skip this lesson.

A state machine is often part of a larger system.

So far, our designs have mostly been calling global functions to interact with the outside world. This is a simple way to get started, but it's not the only way to interact with the outside world. In this lesson, we'll look at a few ways to connect your state machine to other code.

Each language has various technical options for connecting your state machine to the outside world:

See RenderConfig options for your particular language.

I recommend starting with the simplest option that works for your project.

You can also mix and match techniques. StateSmith doesn't care. Do what works best for you.

I recommend reading the following sections in order.

Very simple. This usually works best if you only have a single state machine instance. This is what we've been doing so far.

Your state machine doesn't need to call functions or access globals to be useful. It can simply use input and output variables.

See ./variable-based/ for more details.

If you are using C (or C style C++), check out this .inc file tutorial.

You can generate a .inc file instead of a .c file and then include it in your main file.

Instead of relying on globals, we can give our state machine a reference to an interface/context object that provides functions/variables to the state machine.

See ./composition/ for more details.

We can connect our state machine to other handwritten code by using inheritance. In the below image LightSmBase is handwritten code. It provides functions and variables to the state machine.

See ./inheritance/ for more details.

Similar to inheritance approach.

The next lesson covers language specific details.

Head on over to lesson 4 README.md.