3

Problem

I have a big state machine. The design requirements of the project have changed such that I need to re-use this state machine in another place. All the states remain the same in this new place, but a few states run slightly different stuff. What design pattern allows me to reuse this state machine?

Motivation

I am building a video player. It is modeled by a state machine with these states: stopped, loading, playing, paused, crashed, and some more... This video player needs to be used on two web pages. When the player crashes on the first page, it should show an error message below. If the player crashes on the second page, the error message should appear in the center of the video and pulsate a few times.

Improve this question
4
  • 1
    Don't know if your environment allows this, but if it has eventing support, simply have the state change send out an event - the different pages can subscribe to this event and react in their own way.
    – Oded
    Jul 6, 2012 at 20:13
  • How are those state machines implemented? I imagine it could be easy with adding list of states, list of transitions and the difference between those two players would be difference in one transition.
    – Euphoric
    Jul 6, 2012 at 20:15
  • Can you add slightly different named procedures to your state engine? The one that we use for dialogic interaction runs various procedures based on the code coming back from the card. If we add anything to that list coming back from the card, we simply assign that event to a new procedure, and insert it into the engine definition.
    – JohnP
    Jul 6, 2012 at 20:19
  • The "state machine" solution is a good solution. It's how for example SCXML is working.
    – ysdx
    Jul 6, 2012 at 20:28

2 Answers 2

Reset to default
1

The basic concept is to abstract out what varies. So, if you have a state that does FOO one way in place A, and FOO differently in place B, abstract out FOO into several strategies:

FooAStrategy does what place A needs. It is invoked by calling doFoo, or execute, or some such thing. FooBStrategy does what place B needs. It is invoked by calling doFoo, or execute, or some such thing.

The FooState in place A would have a FooAStrategy. The FooState in place B would have a FooBStrategy.

Each would invoke its strategy as needed.

In case you hadn't guessed, this is the Strategy pattern.

Improve this answer
0

personally, I would have state changes call a method based on an interface - that way you can plug any compatible model into it

as for your specific example, you could subclass the video-player code and override the 'Crashed' state method to provide different behaviors

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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