I've got the following state diagram that can be seen in Webgraphviz:

digraph reload_states {
    node [shape = doublecircle]; Requested;
    node [shape = circle];
    Requested       ->  Requested       [ label = "Reschedule" ];
    Requested       ->  Approved        [ label = "Approve" ];
    Requested       ->  Canceled        [ label = "Cancel" ];
    Approved        ->  Standardized    [ label = "Standardize" ];
    Approved        ->  Canceled        [ label = "Cancel" ];
    Standardized    ->  Queued          [ label = "Queue" ];
    Standardized    ->  Canceled        [ label = "Cancel" ];
    Queued          ->  Running         [ label = "Run" ];
    Running         ->  Succeeded       [ label = "Succeed" ];
    Running         ->  Failed          [ label = "Fail" ];
    Succeeded       ->  Completed       [ label = "Complete" ];
    Succeeded       ->  Canceled        [ label = "Cancel" ];
    Failed          ->  Queued          [ label = "Queue" ];
    Failed          ->  Canceled        [ label = "Cancel" ];


This seems to be medium complexity and I cannot decide between two possible implementations:

  1. Store current state as enum and have method for each transition in the entity
  2. Implement state pattern and encapsulate each state and its' logic in a separate object that represents concrete state

I've never implemented state pattern and I'm quite curious to do so, but I want someone with more experience to measure whether it isn't an overkill for my use case?

I was reading this article to understand what pros and cons it provides.

1 Answer 1


If you have no reason to think that you will need to know more information than just the label text, then yes, the State pattern is a serious overkill. You only need a lookup table to return the label. Even should you need more information in the future, you can return the data in its own bean class dedicated to the task.

I would recommend State Pattern only if the behavior changes according to its state, and even then, only if there are radical variations in behavior. For example, if you decide to set a label only if it is present, this is still entirely feasible adding a simple check in the logic of the class performing the transition.

If you have reason to think that the scenario is more complicated than what you presented, please update your question and I'll re-evaluate my answer.

  • Nah, scenario isn't really more complicated and I've given all details in my question. Canceling in any state means canceling and logic does not change. Reschedule method can be called only when state is Requested but this is fairly easy to control. Thank you Neil. Sep 17, 2018 at 8:21
  • @EvaldasBuinauskas I get that you want to use State Pattern. I've been there. But you shouldn't force the pattern if it doesn't fit. :)
    – Neil
    Sep 17, 2018 at 8:28
  • And that's the exact reason I am here and wanted a second opinion. I'll obviously try it out, maybe even on the same model, but just as an exercise for myself :) Sep 17, 2018 at 8:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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