Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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!

share|improve this question

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
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. –  Henry Gomersall Jul 9 '12 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. –  Joost van Stuijvenberg Jul 9 '12 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!). –  Henry Gomersall Jul 10 '12 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.

share|improve this answer
    
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). –  Henry Gomersall Jul 9 '12 at 8:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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