Introduction to State Oriented Programming
State Oriented Programming is a way of thinking about programming not as process flow but as state and behaviour. With traditional programming, and by traditional I include procedural, functional and OO programming styles, the code will contain conditional statements, usually in the form of 'if' statements, with, possibly, case/switch statements, but it will almost certainly contain some form of logic to decide whether an action should be performed or not. The purpose of the conditional checks will be varied, but it would be a strange program that did not contain any conditional statements.
Some of the pros to using conditional statements
- They match our thought processes
- It is difficult to envisage any other mechanism
- If they are not too complex then it is easy to understand what is being tested and what action will be executed if the test is true
- If what is being tested is local then it is easy to determine how the condition will be triggered
The cons to using conditional statements are really summed up in the caveats attached to the last two pros - If the tests are not too complex and if what is being tested is local. The problem with conditionals is that the condition being tested may not related to the local code. If what is being tested are conditions set-up in another section of code, possibly completely unrelated with code checking the condition, then it can be nigh impossible to track down why the condition is in the state that it is. Which means when something goes wrong it can be extremely difficult to work out why it went wrong. You can find yourself in that classic situation where the only information is "The Computer it say No".
I am sure the following is a scenario we all recognise: repeatedly, in the debugger, stepping through the same code, using same start conditions, setting up complex watch statements in a vain attempt to track down the chain of events that lead to the object or objects under test being set to the state that caused the problem. And when the problem is finally understood, asuming if it ever is, it could well be that it is either too complex to resolve, or resolving it at the start of the events too risky, or it may even be a valid scenario that had not previously been considered. Whatever the reason, the solution, all to often, is to "Add in another 'if' statement to trap the condition, thereby solving this instance of the problem, but making the code more complex, less maintainable, and more likely to cause problems in the future.
State Oriented Programming attempts to reverse the 'if this then that' processes. Instead of testing the state of an object (or objects) and then conditionally executing some behaviour, SOP sets the behaviour that is needed at the point where the object or objects move(s) into the required state, The behaviour can then be execute either at the point of state transition (event driven paradigm) or injected into the code where the 'if' statement would have been (procedural paradigm)
The key points about SOP are that:
- It changes the thought processes from procedural to state. It makes you think about state and state transisions
- It elimiates 'if' statements - which reduces complexity
- It associates the behaviour change with the object state change. When the object changes state you can see the effect it has. The state change and behaviour change are tied together code wise