If you only have two states for an object, is it worth it to still use the State Design pattern?
The context is a multi-player, turn-based game environment where there are Game “Tables” that a player can join, by either entering or leaving a seat.
So, I was focusing on the Seat object to start, as a way of trying to implement recent learning on design patterns.
Generally speaking, the Seat has two states: Vacant or Occupied.
When a seat is Vacant, a player may join it.
When a seat is Occupied, no other players may join and only the Player who has already joined, may leave.
This leads me to my other question…what if one of the states of the Seat is affected by a state in another object, the Game.
The Game object will also have various states. An example of this is, when all 4 players join the table and press Start, the game is considered to be IN PROGRESS.
Consequently, if a Player leaves a seat at this time, for example, by being disconnected, then the seat goes into a “third” state which is a Hiatus State where the spot is reserved for that player to return…but if the game is NOT in progress, then the player may leave the seat freely and it is not reserved.
How would the relationship between the two states be modelled? Would you add a third state to the States a seat can have?
Or is there some parent context that has both a GameState reference and SeatState reference and the “extra state” is handled there?
Any help or insight into the right direction would be much appreciated.
2
The Wikipedia article for State Pattern has a Java example that illustrates two states, involving two different methods. Those methods can be arbitrarily complex, so I consider a two-state solution (no pun intended) perfectly valid.
interface Statelike {
void writeName(StateContext context, String name);
}
class StateLowerCase implements Statelike {
@Override
public void writeName(final StateContext context, final String name) {
System.out.println(name.toLowerCase());
context.setState(new StateMultipleUpperCase());
}
}
class StateMultipleUpperCase implements Statelike {
/** Counter local to this state */
private int count = 0;
@Override
public void writeName(final StateContext context, final String name) {
System.out.println(name.toUpperCase());
/* Change state after StateMultipleUpperCase's writeName() gets invoked twice */
if(++count > 1) {
context.setState(new StateLowerCase());
}
}
}
Note that writeName swaps out its own implementation by handing a new StateLike object to the StateContext when the i count exceeds one.
class StateContext {
private Statelike myState;
StateContext() {
setState(new StateLowerCase());
}
/**
* Setter method for the state.
* Normally only called by classes implementing the State interface.
* @param newState the new state of this context
*/
void setState(final Statelike newState) {
myState = newState;
}
public void writeName(final String name) {
myState.writeName(this, name);
}
}
A State Pattern would be indicated if your “machinery” substantially changes between states. The complexity of the condition needed to choose the correct processing object doesn’t matter; it’s the complexity of the state objects themselves that are the deciding factor. Otherwise, you could just write all of the logic into a single class.
Think about what happens when you build a car. The chassis moves along an assembly line and stops at a station where the welding takes place. Once that state has completed, the chassis moves to the next station on the assembly line, where a different set of robots with completely different programming installs the engine.
7