Talk:State pattern

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Assertion that article is not State Design Pattern with discussion[edit]

Edit 2005.10.20: Note that this is NOT the State design pattern, but instead a simple example of inheritance, which is a fundamental object oriented principle that the complete State pattern takes advantage of. For a correct and definitive reference, see "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. 12.105.87.36 (Moved from main page to talk by BenFrantzDale.)

I disagree. Go back and look at Patterns and note that their use of a connection state mirrors the example given here. Furthermore, they mention a photoshop-style tool as another potential application of the pattern. —BenFrantzDale 02:11, 21 October 2005 (UTC)[reply]
According to this url the important feature that the example on this wiki page is missing is that The difference in behavior should be delegated to objects that represent this state. In other words, an object that just changes its behavior depending on what its internal state is is not really an interesting design pattern. Lots of classes do that. If you want to change the way the class behaves when in a certain state, you may still have to go into the class and make lots of complex changes in lots of different functions, especially if your class has a large interface. What if you have 100 states? What if you want to add a new state that's similar to an existing state except for a few small differences in behavior? With the "State" pattern, these states are represented by objects themselves. If you want to change the way the Context behaves when in a given state, you change the implementation of just that state class. If you want to add a new state that is similar to an existing state, subclass an existing state. Etc.


I will note that the code example on the referenced page has a small error -- it has a class modifying a private member in another class. However, this is obviously just a mistake, the same idea could easily be implemented without this illegal access (for example, have the Handle method return the State object)
I think my example may be ambiguous in that the subclass has some internal state despite following a state pattern at a higher level. I added a second subclass—a rectangular selection class—to clarify. Does this help? —BenFrantzDale 02:42, 24 October 2005 (UTC)[reply]
This example is correct. It closely follows the example shown in the diagram under "Known Uses" of the State Pattern in the Gang of Four book. Would it help if we explictly listed the client like the GoF does? Babomb 19:50, 24 October 2005 (UTC)[reply]
I appreciate the responsiveness here, and after reviewing it more, I understand where you are coming from,and apologize for any confusion.
It is actually the example itself. The model, as described in the book, is an interesting one. In it, the DrawingController is the object containing state, and the Tool is the state itself. In seeing your example without the controller, the usage of the name Tool makes your objects appear to model nouns in a domain. It seems like the Tool is the object with state, and that you're modelling simple static state via inheritance, when in fact the Tool is the state itself for a dynamic parent. I hadn't recalled this example, and didn't make the connection right away. If you look at the TCPConnection example from the book, the fact that the "state" side of the pattern models specific states is more clear, with language such as "Established", "Closed", etc., and if the TCPConnection context object was removed, as in your example, it may have still made some sense.
In your example, you state "The state of the drawing tool is thus represented entirely by an instance of AbstractTool", the fact that the "AbstractTool" refers to the state of the "drawing tool", which is an external object not represented here, is unclear. But, it does say "The state of", so you are definitely correct. It's all in the wording, and that's my fault.
Admittedly, I think the language is ambiguous and misleading, but on the other hand, the message you were trying to express was absolutely right. My suggestion would be to change the example to one where the language more clearly expresses the modelling of states (such as "connected", "running", "offline", "pending", "rerouting", "cancelled", etc.), or at least put special focus on the fact that the Tool classes are modelling the state of some parent object.
And as you proposed, perhaps simply adding the context would solve it.
nanjoutai 03:02, 8 November 2005 (UTC)[reply]
So please somebody with acces to the Socket example do the change! I've somehow taken the idea, and I share that the example, as given, is nothing but inheritance. So I'm willing to see the good example! =) -- User:Euyyn 28-Nov-05
I agree this is Not an example of the state pattern and is inheritance. From the text a reader would assume that each state transition, which is an event/action function, would be bound to a fixed set of events, represented by the methods of the abstract interface, and that only the actions of the transitions, represented by the statements of the overloaded methods, are variable. This is just not the case in the state pattern, but this is the case in inheritance when a method is overloaded. In the state pattern each state transition is defined by a tuple of (event, action) pairs, with an optional guard to handle orthoginal concerns. There is no restriction that the domain of the transitions be restricted as the example and text proports by the use of an interface, thus each state can have it own domain of events that are either the same or different.
What bothers me in all these examples and theory is this: every state is aware of the next state the transition has to happen to. This means the transition logic is spread across multiple classes. Also, the state transition is not decided by a mapping table (=> in a state machine <Σ,S,s0,δ,F>, the δ is absent.) Would this be theoretically correct? In OO lingo, the states are intelligent objects, not representational entities. The flip side of which, I can see, is the states are tied to, and decide a particular control flow; they do not represent the 'state's of the machine. Or may be I am totally missing something. - Sipayi 15:54, 20 November 2007 (UTC)[reply]


my understanding[edit]

I don't think the sample here is of the state pattern neither. My understanding is that each of the state in the context space should be represented by a concrete class of the type with its implementation of the action(s) including state change. And the object keeps the current state value throughout the procedure.

I have added a client to the code, which I hope will clear up the confusion. This drawing tools example is very similar to that in the diagram on p. 313 of the GoF book. Babomb 06:25, 18 March 2006 (UTC)[reply]
The example is still wrong, as is the whole article. The crucial difference between the state design pattern and the strategy design pattern is that the state pattern is a strategy pattern that is responsible for switching to different states, thus actually implementing a state machine. If the example doesn't showcase any transition between states handled by each concrete implementation of the state interface then clearly it doesn't represent a state machine. A state machie, to be an actual state machine, needs to showcase transitions between states, and the examples don't. -- Mecanismo | Talk 15:12, 15 May 2016 (UTC)[reply]

a printer[edit]

I agree your example is not a state pattern, because the "states" (your tools) do not model the transitions. When I use this pattern, not only the operations but also the state transitions are delegated to the states themselves. Here, your DrawingController controls the whole transition table hence you gain almost no expressiveness over a switch statement.

To me, your example is quite as good an example as one for the Strategy pattern.

I don't quite remember the example the GoF use but here is one involving a two-state printer (in Java): 

package printer;

public class Printer {
   private PrinterState state;
   public Printer () {
      state = new OnLineState(); // default state is on-line
   }
   public void print (Document doc) {
      state = state.print(doc);
   }
}

interface PrinterState {
   PrinterState print (Document doc);
}

class OnLineState implements PrinterState {
   public PrinterState print (Document doc) {
      PrintState nextState = this;
      try {
         doc.print();
      }
      catch (OffLineException x) { // maybe no more paper?
         nextState = new OffLineState();
      }
      return nextState;
   }
}

class OffLineState implements PrinterState {
   public PrinterState print (Document doc) {
      waitOnlineButton();
      return new OnLineState().print(doc);
   }
   private void waitOnlineButton () {
      // implementation not relevant
   }
}

Hope it helps (you may use this code as you see fit, or even delete it if you find it irrelevant)

--Cadrian 14:40, 20 April 2006 (UTC)[reply]

--Anon I think this version is the best on this discussion page - concise and clear

-- looks like a very nice example to me

Another Example[edit]

Here is a good example of the state pattern I have from my university notes (hope the lecturer doesn't mind me putting this on here!). I am currently revising my notes and I found this example extremely useful for the state pattern. The other good example is a TCP session because it goes through states in a state machine manner whereby one state initiates the change of state itself.

Anyway, here is the example of a FrameImage and FrameType (the state) pattern. Here the FrameType, the state, can be changed by the user thus making the code a lot simpler when we want to allow the user to be able to quickly change the type of frame we have around an image.

---NOTE: The example below is actually the "bridge" pattern. 

class FrameType {
 public:
  virtual void draw_frame(int width, int height)=0;
};

class PlainFrame : public FrameType {
 public:
  virtual void draw_frame(int width, int height);
};

class FancyFrame : public FrameType {
 public:
  virtual void draw_frame(int width, int height);
};

class FramedImage {
 public:
  void draw_frame();
 private:
  FrameType* frametype;
  int width;
  int height;
};

void FramedImage::draw_frame() {
 frametype->draw_frame(width, height);
}


Need Better Example[edit]

I am someone that has recently become familiar with the State pattern. I have to agree that the implementation of drawing tools is not a good example problem for this pattern. The key issue is that drawing tools really don't go through state transitions.

Take a digital watch as a better example. As you press various buttons, you enter different modes (or states) where buttons take on different functions. You might enter a time edit mode, or stopwatch mode, or heartrate mode, etc. The user interacts with the digital watch using the same buttons, but they have different meanings in the different contexts. This is a much better example problem to model using the State design pattern.

please comment[edit]

Hi All, I am going through different patterns currently. I had tried to implement the State pattern with this example. Please comment whether this example is correct or not. BTW, I have taken it from GOF's book. //Example of State Pattern 

#include <iostream.h>

class Context;
class State;
class FirstState;
class SecondState;
class ThirdState;

class State
{
public:
	//State(Context* t):m_t(t){}
	virtual void FirstFunction(Context* t){}//has been implemented in the first state
	virtual void SecondFunction(Context* t){}//has been implemented in the second state
	virtual void ThirdFunction(Context* t){}//has been implemented in the thirs state

protected:
	void StateChange(Context* t, State* s);//{t->StateChange(s);}//has been implemented later
private:
	//Context* m_t;
};


class FirstState : public State
{
public:
	
	FirstState(){}

	void FirstFunction(Context* t);
	/*
	{
		cout<<"Inside first state. It will turn on second state."<<endl;
		StateChange(t, SecondState::Instance());
	}
	*/

	static State* Instance()
	{
		return new FirstState();
		/*
		if(FirstStateInstance == 0)
			FirstStateInstance =  new FirstState();
		return FirstStateInstance;
		*/
	}
private:
	static State* FirstStateInstance;
	
};

class SecondState : public State
{
public:
	SecondState(){}

	void  SecondFunction(Context* t);
	/*	
	{
		cout<<"Inside second state. It will turn on third state."<<endl;
		t->ChangeState(ThirdState::Instance());
	}
	*/
	

	static State* Instance()
	{
		return new SecondState();
		/*
		if(instance == 0)
			instance =  new SecondState();
		return instance;
		*/
	}
private:
	static State* instance;
};


class ThirdState : public State
{
public:

	ThirdState(){}
	void ThirdFunction(Context* t)
	{
		cout<<"Inside third cum last state."<<endl;
	}

	static State* Instance()
	{
		/*
		if(instance == 0)
			instance =  new ThirdState();
		return instance;
		*/
		return new ThirdState();
	}
private:
	static State* instance;
};


//enum PresentState{State1 = FirstState::Instance(), State2 = SecondState::Instance(), State3 = ThirdState::Instance()};

class Context
{
public:
	Context() {stateObj = FirstState::Instance();}
	void FirstFunction()
	{
		stateObj->FirstFunction(this);
		SecondFunction();
	}
	void SecondFunction()
	{
		
		stateObj->SecondFunction(this);
		ThirdFunction();
	}
	
	void ThirdFunction()
	{
		stateObj->ThirdFunction(this);
	}

	void StateChange(State* s){stateObj = s;}
	
private:
	State* stateObj;

};

void State::StateChange(Context* t, State* s){t->StateChange(s);}

void FirstState::FirstFunction(Context* t)
{
	cout<<"Inside first state. It will turn on second state."<<endl;
	StateChange(t, SecondState::Instance());
}

void  SecondState::SecondFunction(Context* t)
{
	cout<<"Inside second state. It will turn on third state."<<endl;
	t->StateChange(ThirdState::Instance());
}

void main()
{
	Context* context = new Context();
	context->FirstFunction();
}
That looks about right. Do note that you leak memory, though. Obviously you leak the Context you new in main() (which doesn't really matter here but is sloppy), but you also haven't defined a destructor for Context so it's not clear who should be deleting the State a Context has a pointer to. Since the State objects appear to be singletons, I'd guess you don't plan to delete them, but if they are singletons, they should have a private destructor so you don't accidentally make other instances of them. Also, you'll need to initialize the instance pointers to NULL or else checking for nullness won't do what you want. —Ben FrantzDale 11:32, 19 June 2006 (UTC)[reply]

Circular dependencies are never good. A common mistake when implementing the state pattern. —Preceding unsigned comment added by 213.65.6.77 (talk) 16:51, 4 November 2008 (UTC)[reply]

Internal State vs Behavioural Strategy[edit]

This is definitely not a State pattern realization. States represent internal state of a system that alters/transitions over interactions, thereby altering behaviour. The crucial point here is that States must be transitory and the transitions must be internal to the object whose state is being abstracted.

The exapmle presented is clearly a realization of a Strategy pattern where the DrawingController abstracts mouse interaction into a generic Tool with two Tool implementations that exhibit different interaction behaviours. Neither Tool transitions into the other, nor is the Tool interface capable of transitions.

The State pattern is actually a modelling of UML State charts. Hence the necessity of internal event-based transitions.

PS- The Tool analogy was more aptly used in GoF as a realization of the Prototype pattern. --203.197.90.149 07:48, 23 June 2006 (UTC)[reply]

I maintain that the example is a realization of the State pattern, and refer to the similar example on p. 313 of GoF. The current tool selected represents the state of the drawing controller. I believe the confusion stems merely from the way the example is presented.

The Tool interface need not be capable of transitions. From p. 308 of GoF, "The State pattern does not specify which participant defines the criteria for state transitions. If the criteria are fixed, then they can be implemented entirely in the Context."

Nevertheless, I would not be adverse to a replacement example if only to end this argument. By all means, go ahead and write one. --Babomb 23:11, 23 June 2006 (UTC)[reply]

How about this implementation[edit]

Please comment on this Sample Example Dear All, Here is my version of the state Pattern. Please comment on this. Previously I submitted another sample, but this one is implemented differently. I also wanted to upload the class diagrams and the sequence diagram of this sample. But I am not sure how to do that. 

#include <iostream.h>

class Context;

class State;

class FirstState;

class SecondState;

class ThirdState;

class State

{

public:

	virtual void FirstFunction(Context* t){}//this will implement the function of the first state

	virtual void SecondFunction(Context* t){}//this will implement the function of the second state

	virtual void ThirdFunction(Context* t){}//this will implement the function of the third state

};


class FirstState : public State

{
public:
	
	FirstState(){}

	void FirstFunction(Context* t);//Implementation later in the file
	
	static State* Instance()
	{
		if(FirstStateInstance == NULL)

			FirstStateInstance =  new FirstState();

		return FirstStateInstance;
		
	}
private:

	static State* FirstStateInstance;

	~FirstState(){};
	
};

State* FirstState::FirstStateInstance = NULL;

class SecondState : public State

{

public:

	SecondState(){}

	void  SecondFunction(Context* t);//Implementation later in the file
		
	static State* Instance()
	
        {

		if(SecondStateInstance == NULL)

			SecondStateInstance =  new SecondState();

		return SecondStateInstance;
		
	}
private:

	static State* SecondStateInstance;

	~SecondState(){}

};

State* SecondState::SecondStateInstance = NULL;

class ThirdState : public State

{

public:

	ThirdState(){}

	void ThirdFunction(Context* t)
	
        {

		cout<<"Inside third cum last state."<<endl;

	}

	static State* Instance()

	{
		
		if(ThirdStateInstance == 0)

			ThirdStateInstance =  new ThirdState();

		return ThirdStateInstance;

		}

private:

	static State* ThirdStateInstance;

	~ThirdState(){}

};

State* ThirdState::ThirdStateInstance = NULL;

class Context

{

public:

	enum EState{EFirstState,ESecondState,EThirdState};

	Context()
 
	{

		stateObj = FirstState::Instance();

		PresentState = EFirstState;
	
       }

	void Run()

	{

		switch(PresentState)

		{

		case EFirstState:

			stateObj->FirstFunction(this);

			break;

		case ESecondState:

			stateObj->SecondFunction(this);

			break;

		case EThirdState:

			stateObj->ThirdFunction(this);

                        break;
		
                }

	}

	void StateChange(State* s, EState state)

	{

		stateObj = s;

		PresentState = state;
	
       }

	~Context()
	
         {

		delete stateObj;

		stateObj = NULL;
	
          }
	
private:

	State* stateObj;

	int PresentState;

};

void FirstState::FirstFunction(Context* t)

{

	cout<<"Inside first state. It will turn on second state."<<endl;

	t->StateChange(SecondState::Instance(), t->ESecondState);

	t->Run();

}

void  SecondState::SecondFunction(Context* t)

{
	cout<<"Inside second state. It will turn on third state."<<endl;

	t->StateChange(ThirdState::Instance(), t->EThirdState);

	t->Run();

}

void main()

{

	Context* context = new Context();

	context->Run();

	delete context;
}


--Som mukhopadhyay 11:32, 17 July 2006 (UTC)[reply]

I would prefer a more concrete example, whether a socket or something silly like Bruce Eckel's of a princess kissing a frog. Also, I don't like that you have conditional logic inside the context that determines the function to call based on the state. One of the main points of the state pattern is to remove this sort of conditional logic, e.g.,

--NOTE: the code below is actually the "template method" pattern —The preceding unsigned comment was added by 71.228.196.3 (talk • contribs) 03:45, 19 December 2006 (UTC).[reply]

---No, template method means the client calls a function in the base class, and that function calls methods overridden by the derived class. In this example, the client merely calls a function that's overridden by the base class, i.e., "normal" polymorphism. And even if the example DID use a template method, that wouldn't necessarily mean it wasn't also a state pattern. -Babomb 04:58, 20 June 2007 (UTC)[reply] 


class State

{

public:

	virtual void SomeFunction(Context* t){}

};

...

void Context::Run()

{
	stateObj->SomeFunction(this);
}
...

void FirstState::SomeFunction(Context* t)

{

	cout<<"Inside first state. It will turn on second state."<<endl;

	t->StateChange(SecondState::Instance(), t->ESecondState);

	t->Run();

}

void SecondState::SomeFunction(Context* t)

{
	cout<<"Inside second state. It will turn on third state."<<endl;

	t->StateChange(ThirdState::Instance(), t->EThirdState);

	t->Run();

}

void ThirdState::SomeFunction(Context* t)

{
	cout<<"Inside third state."<<endl;

}

--Babomb 01:30, 19 July 2006 (UTC)[reply]

TCPConnection class the GoF book[edit]

In the hope this helps the discussion a bit, this is the code copied from the book (Design Patterns : elements of reusable object-oriented software / Erich Gamma [et al.] ISBN 0-201-63361-2 pages 309 through 312), but without the explanations that are between the code snippets: 

class TCPOctetStream;
class TCPState;

class TCPConnection {
public:
	TCPConnection();
	
	void ActiveOpen();
	void PassiveOpen();
	void Close();
	void Send();
	void Acknowledge();
	void Synchronize();
	
	void ProcessOctet(TCPOctetStream*);
private:
	friend class TCPState;
	void ChangeState(TCPState*);
private:
	TCPState* _state;
};

{ ------------------------------------------------------------------ }

class TCPState {
public:
	virtual void Transmit(TCPConnection*, TCPOctetStream*);
	virtual void ActiveOpen(TCPConnection*);
	virtual void PassiveOpen(TCPConnection*);
	virtual void Close(TCPConnection*);
	virtual void Synchronize(TCPConnection*);
	virtual void Acknowledge(TCPConnection*);	
	virtual void Send(TCPConnection*);
protected:
	void ChangeState(TCPConnection*, TCPState*);
};

{ ------------------------------------------------------------------ }

TCPConnection::TCPConnection () {
	_state = TCPClosed::Instance();
}

void TCPConnection::ChangeState (TCPState* s) {
	_state = s;
}

void TCPConnection::ActiveOpen () {
	_state->ActiveOpen(this);
}

void TCPConnection::PassiveOpen () {
	_state->PassiveOpen(this);
}

void TCPConnection::Close () {
	_state->Close(this);
}

void TCPConnection::Acknowledge () {
	_state->Acknowledge(this);
}

void TCPConnection::Synchronize () {
	_state->Synchronize(this);
}

{ ------------------------------------------------------------------ }

void TCPState::Transmit(TCPConnection*, TCPOctetStream*) { }
void TCPState::ActiveOpen(TCPConnection*) { }
void TCPState::PassiveOpen(TCPConnection*) { }
void TCPState::Close(TCPConnection*) { }
void TCPState::Synchronize(TCPConnection*) { }

void TCPState::ChangeState (TCPConnection* t, TCPState* s) {
	t->ChangeState(s);
}

{ ------------------------------------------------------------------ }

class TCPEstablished : public TCPState {
public:
	static TCPState* Instance();
	
	virtual void Transmit(TCPConnection*, TCPOctetStream*);
	virtual void Close(TCPConnection*);
};

class TCPListen : public TCPState {
public:
	static TCPState* Instance();
	
	virtual void Send(TCPConnection*, TCPOctetStream*);
	// ...
};

class TCPClosed : public TCPState {
public:
	static TCPState* Instance();
	
	virtual void ActiveOpen(TCPConnection*);
	virtual void PassiveOpen(TCPConnection*);
	// ...
};

{ ------------------------------------------------------------------ }

void TCPClosed::ActiveOpen (TCPConnection* t) {
	// send SYN, receive SYN, ACK, etc.
	
	ChangeState(t, TCPEstablished::Instance());
}

void TCPClosed::PassiveOpen (TCPConnection* t) {
	ChangeState(t, TCPListen::Instance());
}

void TCPEstablished::Close (TCPConnection* t) {
	// send FIN, receive ACK of FIN
	
	ChangeState(t, TCPListen::Instance());
}

void TCPEstablished::Transmit (TCPConnection* t, TCPOctetStream* o) {
	t->ProcessOctet(o);
}

void TCPListen::Send (TCPConnection* t) {
	// send SYN, receive SYN, ACK, etc.
	
	ChangeState(t, TCPEstablished::Instance());
}

83.80.64.20 13:54, 15 September 2006 (UTC)[reply]

The example currently on the page appears to be an attempt at the secondary example of the State pattern in Design Patterns. I agree that it is not currently an example of the state pattern, but could be made into one if AbstractTool is made into a concrete class that contains the SpecificTool as the State object. Tool would then change the specific tool internally in response to events and obfuscates these internal changes from DrawingController. --209.242.136.2 01:28, 9 February 2007 (UTC)[reply]

Example in Python[edit]

Consider this example of a state machine coded in Python. Don't try this at home in C++. 

# State Machine example Program

from StateDefn import *

class MyMachine(object):

    # Create Statedefn object for each state you need to keep track of.
    # the name passed to the constructor becomes a StateVar member of 
    # the current class. e.g. if myObj is a MyMachine object and "gstate"
    # is the argument to the constructor, myObj.gstate becomes the instances
    # state variable.
    Gstate = StateTable("gstate")
    Tstate = StateTable("turtle")

    def __init__(self, name):
        # must call init method of class's StateTable object. to initialize state variable
        self.Gstate.initialize(self)
        self.Tstate.initialize(self)
        self.mname = name
        self.Acount = 0
        self.Bcount = 0
        self.Ccount = 0

    # Decorate the Event Handler virtual functions -note Gstate parameter
    @EventHandler(Gstate)
    def EventA( self ): pass
    @EventHandler(Gstate)
    def EventB( self ): pass
    @EventHandler(Gstate)
    def EventC( self, val ): pass

    @EventHandler(Tstate)
    def Toggle(self): pass


    # define methods to handle events.
    def _eventAHdlr1(self):
        print "State 1, event A"
        self.Acount += 1
    def _eventBHdlr1(self):
        print "State 1, event B"
        self.Bcount += 1
    def _eventCHdlr1(self, val):
        print "State 1, event C"
        self.Ccount += 3*val

    def _eventAHdlr2(self):
        print "State 2, event A"
        self.Acount += 10
    def _eventBHdlr2(self):
        print "State 2, event B"
        self.Bcount += 10
    def _eventCHdlr2(self, val):
        print "State 2, event C"
        self.Ccount += 2*val

    def _eventAHdlr3(self):
        self.Acount += 100
        print "State 3, event A"
    def _eventBHdlr3(self):
        print "State 3, event B"
        self.Bcount += 100
    def _eventCHdlr3(self, val):
        print "State 3, event C"
        self.Ccount += 5*val
    
    # Associate the handlers with a state. The first argument is the name of the 
    # state. The second argument is a list of methods.
    # One method for each EventHandler decorated function of Gstate. Order of methods
    # in the list correspond to order in which the Event Handlers were declared.
    # Third argument defines the states to transition into when event occurs.
    #
    # The first state created becomes the initial state.
    _state1 = Gstate.State("One",  (_eventAHdlr1, _eventBHdlr1, _eventCHdlr1 ), 
                                      ("Two", "Three", None ))
    _state2 = Gstate.State("Two",  (_eventAHdlr2, _eventBHdlr2, _eventCHdlr2 ),
                                     ("Three",        None,          "One"))
    _state3 = Gstate.State("Three",(_eventAHdlr3, _eventBHdlr3, _eventCHdlr3 ),
                                 (None,         "One",         "Two"))


    # Declare a function that will be called when entering a new Gstate.
    # Can also declare a leave function using @OnLeaveFunction(Gstate)
    @OnEnterFunction(Gstate)
    def _enterGstate(self):
        print "entering state ", self.gstate.Name() , "of ", self.mname
    @OnLeaveFunction(Tstate)
    def _leaveTstate(self):
        print "leaving state ", self.turtle.Name() , "of ", self.mname


    def _toggleOn(self):
        print "Toggle On"

    def _toggleOff(self):
        print "Toggle Off"

    _t_off = Tstate.State( "Off", [_toggleOn],
                         ["On"     ])
    _t_on =  Tstate.State( "On",  [_toggleOff],
                          ["Off"])


def main():
    bigMachine = MyMachine("big")

    bigMachine.EventA()
    bigMachine.EventA()
    bigMachine.EventB()
    bigMachine.EventC(4)
    bigMachine.EventA()

    bigMachine.Toggle()
    bigMachine.Toggle()
    bigMachine.Toggle()

    bigMachine.EventC(7)
 
    print "Event A count ", bigMachine.Acount
    print "Event B count ", bigMachine.Bcount
    print "Event C count ", bigMachine.Ccount

main()

--64.238.49.65 23:19, 21 March 2007 (UTC)[reply]

Strategy[edit]

I agree this is an example of a strategy pattern. Even if those two are quire related (a well used state is a form of strategy and is not limited to a simple enumeration as it is too often encountered), the pattern state still holds the semantic of internal modifications, and obviously the "state" semantic which is totally absent here, even if extended to the extreme.

This example should be swapped by a correct and meaningful one, requiring not much background, like the traditional online/offline behavior, or the scholar "connexion state" code fragment.

Tobei 10:16, 13 August 2007 (UTC) Bold text[reply]

Stopwatch Sample[edit]

I liked the idea of a stop watch example with buttons changing function as you pushed them. Here's a VB.net example. 

Imports System.Threading

Module Module1
	Sub Main()
		Dim watch As New Watch
		Call CurrentState(watch)
		Console.WriteLine("Sleeping 2 seconds")
		Thread.Sleep(2000)
		Call CurrentState(watch)
		Console.WriteLine("Pushing button and sleeping 2 seconds")
		watch.Push()
		Thread.Sleep(2000)
		Call CurrentState(watch)
		Console.WriteLine("Sleeping 2 seconds")
		Thread.Sleep(2000)
		Call CurrentState(watch)
		Console.WriteLine("Pushing button and sleeping 2 seconds")
		watch.Push()
		Thread.Sleep(2000)
		Call CurrentState(watch)
		Console.WriteLine("Done")
		Console.ReadLine()
	End Sub
	Private Sub CurrentState(ByRef watch As Watch)
		Console.WriteLine("")
		Console.WriteLine("State: " + watch.State)
		Console.WriteLine("Run Time: " + CStr(watch.Time))
	End Sub
End Module

' Common interface, a better example would use a different interface for watch
Public Interface Button
	Sub Push()
	Function Time()
	ReadOnly Property State() As String
End Interface

'Watch (Context)
Public Class Watch
	Implements Button
	Private _button As Button = New ButtonStopped(Me, 0)

	Public Sub Push() Implements Button.Push
		_button.Push()
	End Sub
	Public Function Time() As Object Implements Button.Time
		Return _button.Time()
	End Function
	Public Property Button() As Button
		Get
			Return _button
		End Get
		Set(ByVal value As Button)
			_button = value
		End Set
	End Property
	Public ReadOnly Property State() As String Implements Button.State
		Get
			Return _button.State
		End Get
	End Property
End Class

'Running watch (State)
Public Class ButtonRunning
	Implements Button
	Private _watch As Watch
	Private _time As Integer
	Private _timer As New Timer(AddressOf IntervalElapsed, Me, 0, 1000)

	Sub New(ByVal _watch As Watch, ByVal _time As Integer)
		Me._watch = _watch
		CurrentTime = _time
		Me._time = _time
	End Sub
	Public Sub Push() Implements Button.Push
		_watch.Button = New ButtonStopped(_watch, CurrentTime)
	End Sub
	Public Function Time() As Object Implements Button.Time
		Return CurrentTime
	End Function
	Private Sub IntervalElapsed(ByVal info As Object)
		CurrentTime += 1
	End Sub
	Private Property CurrentTime() As Integer
		Get
			SyncLock _watch
				Return _time
			End SyncLock
		End Get
		Set(ByVal value As Integer)
			SyncLock _watch
				_time = value
			End SyncLock
		End Set
	End Property
	Public ReadOnly Property State() As String Implements Button.State
		Get
			Return "Running"
		End Get
	End Property
End Class

' Stopped watch (State)
Public Class ButtonStopped
	Implements Button
	Private _watch As Watch
	Private _time As Integer
	Sub New(ByVal _watch As Watch, ByVal _time As Integer)
		Me._watch = _watch
		Me._time = _time
	End Sub
	Public Sub Push() Implements Button.Push
		_watch.Button = New ButtonRunning(_watch, _time)
	End Sub
	Public Function Time() As Object Implements Button.Time
		Return _time
	End Function
	Public ReadOnly Property State() As String Implements Button.State
		Get
			Return "Stopped"
		End Get
	End Property
End Class

This is the state pattern[edit]

I just finished the GoF book and this is the prime example they use. A different drawing tool like a pen, selection, or brush represents a state. There are other kinds of states obviously but if they use it in the book I see no issues with this exmpale. I would like to see other language examples but this is a rather lengthy pattern to use. Also of course this is inheritance, how do you think you get the different states? I see no issues with the article other then maybe include some additional languages. j_lechem@msn.com (talk) 23:09, 7 April 2009 (UTC)[reply]

Ok, I'll agree that this is an example of the state pattern. But it's a VERY POOR
example. It would be changed into an example of the strategy pattern by the simple
replacement of the following methods of the cursor class:
    function usePenTool() is
        current_tool := new PenTool

    function useSelectTool() is
        current_tool := new SelectTool
With this one:
    function setTool( tool ) is
        current_tool := tool
That's not a big change. You see, many of us here consider that example in the GOF book to be a bad example,
for the reason I just mentioned. We don't consider that any one reference, here the
GOF to have the final say on this. On the whole, their book is excellent, but it's
not perfect. In particular, many of us dispute this example. --64.238.49.65 (talk) 22:46, 15 June 2009 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:State_pattern&oldid=1205441948"