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.

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.

share|improve this question
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 '12 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 '12 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 '12 at 20:19
    
The "state machine" solution is a good solution. It's how for example SCXML is working. –  ysdx Jul 6 '12 at 20:28

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer

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

share|improve this answer

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.