Reviewed-on: #1
c_state_pattern
A simple example of how to implement the state pattern in c. check main.c for the implementation.
the state pattern is a pattern that aims to get rid of the mess that a state machine causes within your code. So i propose a problem for you, you are trying to write an state machine for a phone, sounds easy your phone only has 3 inputs that change the current state of the phone.
inputs:
- power button
- lock button
- string enter button
the power button does what it says either turns the phone off or on, the lock button too does what it says on the tin locks the phone, lastly the string enter button enters what every string is in the phones buffer this is used for entering things like passwords to unlock the phone.
using these buttons you determine you need 4 states for your phone these are:
states:
- off
- unlock
- locked
- debug
and you want the inter-action between these states to work as follows:
pwr : power button pressed
lck : lock button pressed
str=x : string enter button press with string x
------------ state diagram ------------
pwr ┌──────────┐ pwr
┌─────┴┬────►│off state │◄────┴┐
│ │ └────┬─────┘ │
│ │ │ │
│ │ ┌─────┘ │
│ │ ├ pwr │
│ │ ▼ │
│ ┌──┴─────┐ str=pwd ┌────┴───┐
│ │lock ├─────┴─────►│unlock │
│ │state │ │state │
│ └──────┬─┘◄───┬───────┴──┬─────┘
│ ▲ │ lck │
│ lck ┤ ├ str=dbg ├ str=dbg
│ │ │ │
│ │ │ │
│ │ ▼ │
│ ┌─┴──────┐ │
└───┤debug │◄──────────────┘
│ │
└────────┘
----------- \ state diagram -----------
now you may read these requirements for the device and think ill just implement this with a state machine how bad can it be. Well your tech lead tells you that this systems needs to scaled to over 100 different states as they make the system more complex. you ask him "why do we need this" they reply back with management said so. And so between the idea of getting fired from throwing a brick at the management team and implementing this state diagram you decide you need this job and to implement state pattern. this pattern allows for greater flexibility when creating new states, since you dont have to add to an ever gowning state machine. we do some simple math to see how out of hand this can get, if we assume that you end up with 100 states in the end and each state takes up 20 odd line
100_{\text{states}} \times 20_{\text{loc}} = 2000_{\text{loc}}
that would be a 2k line state machine and a nightmare to debug (i should know ive seen them in the wild)
so to start implement this pattern we first draw up a uml diagram of how it should go together. we can see we have the device itself and which is composed of a device state, and the entered string.
This "class" also has 3 methods pressPwrButton, pressStrInputButton, and pressLockButton. these methods are used to create an abstraction from the device state so the underlying state can change while using the same input functions.
classDiagram
class Device_t{
+DeviceState_t state
+String entered_string
+pressPwrButton() pressPwrMethod
+pressStrInputButton() pressStrInputMethod
+pressLockButton() pressLockMethod
}
class DeviceInterface_s {
+pressPwrMethod()
+pressStrInputMethod()
+pressLockMethod()
}
class DeviceState_t{
+String state_name
+DeviceInterface_s methods
}
Device_t *-- DeviceState_t
Device_t o-- DeviceInterface_s
DeviceInterface_s --o DeviceState_t
(note not real uml diagram because no one knows how to read them)
-
so to implement this we will first start off with the device struct
// device.h typedef struct Device_s{ DeviceState_t state, char* entered_string, } Device_t; -
Next we will implement the methods which in this case will be an interface. These methods are all the changes that can be made to the device i.e. your inputs.
// device.h typedef struct DeviceInterface_s{ void (*pressPwr)(Device_t*); void (*pressStrInput)(Device_t*); void (*pressLock)(Device_t*); } DeviceInterface_t; -
and finally we will implement the struct to hold the actual state of the device. (note there is some funkiness in c with implementing this since you will need forward decls)
// device.h typedef struct DeviceState_s{ const char* state_name; DeviceInterface_t methods; }DeviceState_t; -
now we need to implement the 3 functions for device inputs, ive implemented one here as the rest are very similar. So this function takes the given device and then uses the methods defined within the device state to change the current state of the device.
// device.c void pressPwrButton(Device_t *device) { device->state.methods.pressPwr(device); } -
now we will create a new header file called state, this file will contain the functions that sets the state of the given device to a new state. so we will implement a function per out defined states.
//state.h void setDeviceStateToUnlock(Device_t *device); void setDeviceStateToDebug(Device_t *device); void setDeviceStateToLock(Device_t *device); void setDeviceStateToOff(Device_t *device); -
now we can implement one of these states as the rest of them should be fairly self explanatory. the state we will be implementing is the lock state as this should show off most of the different transitions. we will first start out with implementing the set state function. this function takes the given device and sets that devices state to this new state.
// lock_state.h void setDeviceStateToLock(Device_t *device) { device->state = (DeviceState_t){ .state_name = lock_state_name, .methods = (DeviceInterface_t){ .pressPwr = &pressPwrMethod, .pressStrInput = &pressStrInputMethod, .pressLock = &pressLockMethod, }, }; } -
now that we have the function for setting this state we can now implement the functions for what this functions does depending on the inputs we will first start with the power button function. This is one of the simplest when the power button is press i.e. when the function is called we set the devices state to off.
// lock_state.c static void pressPwrMethod(Device_t *device) { printf("turning off device\n"); setDeviceStateToOff(device); } -
now we will implement the next function the lock button which in the lock state will do nothing.
// lock_state.c static void pressLockMethod(Device_t *device) { (void) device; printf("nothing happens\n"); } -
finally we create the function for handling the text input, this function will check the entered string to see if its either "dbg", or "pwd" and if it is enter debug or unlock respectively.
static void pressStrInputMethod(Device_t *device) { if (strcmp(device->entered_string, "dbg") == 0) { printf("entering debug state\n"); setDeviceStateToDebug(device); return; } if (strcmp(device->entered_string, "pwd") == 0) { printf("entering unlock state\n"); setDeviceStateToUnlock(device); return; } printf("unknown string %s\n", device->entered_string); } -
now we just need to implement the other states in the same way we implemented this first one.
-
finally we need to test our device. firstly within main we create a new device and set its initial state to off.
Device_t device; initDevice(&device); setDeviceStateToOff(&device); -
now we can test that the device correctly travels through each state, by pressing one of the buttons (invoking the input method functions) then checking that the
state_nameis equal to the set state name.// turn on the device pressPwrButton(&device); if (strcmp(device.state.state_name, "lock_state.c") != 0) return 0;
now that you have implement this basic state pattern your tech lead comes to you and tells you to implement one more state then they will let you throw a brick at management as a treat this state is:
- A calling state where:
- when the phone is unlocked you can type in a number in the the string input and it will call it
- you can also turn off the phone from this state
- the lock button ends the current call and returns back to the unlocked state
so try implementing this yourself.
other good resources for learning how this patterns works is bob nystrom's game programming patterns book as well as refactoring Guru however both of these implement this in the fun languages with object and interfaces.
how to build and run it
this demo uses a simple build system called nob a header only build system for c projects.
to build run these command in the root of the project:
# bootstraps the build system
> gcc nob.c -o nob
# runs the build system
> ./nob
# runs the program
> ./build/main
and if you have a different compiler you want to use that is posix compliant just change the CC macro in the nob.c with your one.