Talk:State pattern

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.