I am using a piece of hardware with a well defined C API. The hardware is stateful, with the relevant API calls needing to be in the correct order for the hardware to work properly. The API calls themselves will always return, passing back a flag that advises whether the call was successful, or if not, why not. The hardware will not be left in some ill defined state. In effect, the API calls advise indirectly of the current state of the hardware if the state is not correct to perform a given operation. It seems to be a pretty common hardware API style.

My question is this: Is there a well established design pattern for wrapping such a hardware state machine in a high level language, such that consistency is maintained?

My development is in Python. I ideally wish the hardware state machine to be abstracted to a much simpler state machine and wrapped in an object that represents the hardware. I'm not sure what should happen if an attempt is made to create multiple objects representing the same piece of hardware.

I apologies for the slight vagueness, I'm not very knowledgeable in this area and so am fishing for assistance of the description as well!

  • It's not often advisable to mimick the operation of a hardware FSM in accompanying software - If you can, avoid it. Supply functions to re-set and read the HW state. It's the HW that "should be right" in all cases, anyways.
    – tofro
    Commented Apr 3, 2022 at 8:12

2 Answers 2


So in fact you just want an object oriented wrapper around a C API and it is still possible that an other object using this object calls its methods in an inappropriate way? Many OO languages including Python (although I'm not an expert at it) support the concept of exceptions for this. Consider something like throwing an InvalidStateException if the client code calls a method that is invalid in the current state.

If you want to prevent multiple instances of this object you can implement the Singleton design pattern.

  • This has been my thinking so far, but it seems a bit mucky. It won't actually be a singleton, as multiple hardware devices might be connected. Still, I'm beginning to suspect there is no perfect fit here. Commented Jul 9, 2012 at 9:00
  • If you have one instance for each connected device, that instance can/should still be a singleton. And from your answer to James I get the feeling your problem really is to obtain the current state of your device, since you describe that the device 'tells' you you're in the wrong state. But you might still use that info in order to get into the correct state. If the calling code can handle exceptions you can reissue the same command.
    – user57328
    Commented Jul 9, 2012 at 19:04
  • This is actually how I implemented it - a wrapper around the hardware with exception handling for invalid state. Handily, the hardware interface will only hand out a given handle once (it must be liberated before it will hand it out again), so the instantiation of the class will only happen if the hardware driver lets it, so enforcing this quasi-singleton pattern. It's actually a testament to a very nice hardware API (in contrast to other APIs I've used!). Commented Jul 10, 2012 at 15:05

What's wrong with just keeping track of the state in an int? Then on each API call you check if the operation is allowed in the current state, although this can get tedious if there are tens or more states.

If you really feel the need to go all design patterny then maybe the State Pattern would interest you.

  • The problem is that the state is not trivial to establish explicitly. It's done by telling you you're in the wrong state and why you're in the wrong state (i.e. some parameter has not been set up). Commented Jul 9, 2012 at 8:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.