![]() I notice a difference with state Pattern. In this case state is a simple enum property of the Order class, thus using state machine is much better. ![]() You only care if the order is in "added_to_cart" state, when a "payment_finished" event is published, then change it to "processing" state. State pattern will be useful if the behavior of each state is important, e.g in game programming, where an object can have states like "idle", "attack", "run" and in each state you want to implement the behavior of the object.īut for use case like ordering online products, where you don't care how the order object behaves. Saying state pattern makes state machine obsolete is incorrect. Each state will be a separate class, having doAction() method of its own. The transition is just an implementation details to make your state behaviors decoupled from each other. On the other hand, in state pattern, you don't really care about the transition, but how the object behave in those states. If you implement a state machine in Java, a state will be just an enum, or a String and there will be a Transition class with doAction() method. In fact, we only care what action is applied when the object is transitioned to the next state. In state machine, the object can be in different states, but we don't really care how they behave in those states. In case anyone still interested, here is my view: One Argument for the state pattern is that it allows the implementation of "Open Closed" state machines where a state machine can be defined in a library and then expanded on by the user, this is not possible as far as I know with mainstream state machine frameworks. The author is correct that the initial implementation is usually easier with the state pattern compared to a state machine and that generally more programmers should use more state machines. I do use the state pattern in cases where speed is a non issue and where the hierarchy of the state machine will most likely remain flat. The author is right that adding a state is easier but only very minimally, with boost statecharts for example I only have to add the state to the list of its parents child states, that is the only real difference. I also prefer seeing all transitions in a table rather than looking through the inner workings of every state. Also the addition of a new event type/handler function requires adding a function to all states! I don't consider that maintenance friendly. This is also a potential efficiency killer depending on your requirements.įrom a maintenance standpoint it should be noted that logging unhandled events cannot be done from one central superstate with the state pattern. However this would require major changes to the Authors example.Īlso notice that events that are not handled cannot be inlined and optimized away like in static state machines because with the state pattern they are behind a layer of dynamic indirection. This could be remedied by placement allocating all states in a buffer next to each other in order to save a cache miss or two. Notice that switching states requires an allocation! this is going to kill speed. The idea that the authors implementation is particularly short or simple or that it requires less maintenance than the boost statecharts digital camera depends on your use case and personal taste but can not be said catagorically. ![]()
0 Comments
Leave a Reply. |