3

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.

  • I think the 2 states for seat object is fine, you can model the state for Game object (I think a more suitable object name is Table or GameTable object, since it's natural to think that a Table consists of 4 seats) as you mentioned and use Observer pattern for communication between seat and game. Game object will observe for any changes from any seats that it contains and decide its corresponding state and transition – Phuong Nguyen May 7 '15 at 6:44
  • If the logic for changing states is simple, and you only have two states (and don't expect more), then State Pattern might be overdesign. Consider the solution that's simple. It sounds as if you're looking for a problem to solve with a pattern, rather than the other way around. To use another analogy, just because you have a drill in your toolbox, don't go looking for places to put holes in your house. – Fuhrmanator May 7 '15 at 14:40
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.

  • Thanks for your response Robert. It seems that you have answered the question if two states are two little and it seems the answer is No, only 2 states is not two little depending on if there is complex logic contained within the states. I don't think you answered how to manage the third "composite" state that is affected by another state...is there a best practice for this? – Sean May 6 '15 at 17:11
  • The two-state solution already covers this; just extend the same concept to three states. Did you have a more specific question? The third object can have a constructor that helps you set up the object for the third state. Note that, in my answer, I stated that it didn't matter how complex your deciding conditions are. – Robert Harvey May 6 '15 at 17:16
  • So maybe I'm missing something and you can explicitly highlight it for me. If the Seat has 3 states but the "third" state is determined by some outside info...how to best model this, I gave the specific example in my original question when I mentioned the Hiatus state. – Sean May 6 '15 at 17:19
  • If a Hiatus state is "separate and distinct," then make another object, that's all. The whole point of the pattern is to provide encapsulation between the states, just as my example about the different robot stations where each station has robots that specialize in a particular task illustrates. – Robert Harvey May 6 '15 at 17:19
  • You can find me in here, if you want to discuss this further. – Robert Harvey May 6 '15 at 17:23

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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