Is it worth considering State pattern in this case

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
3
down vote

favorite

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

digraph reload_states 
 rankdir=LR;
 size="8,5"
 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" ];

Diagram

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

Store current state as enum and have method for each transition in the entity

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.

asked 4 hours ago

Evaldas Buinauskas

1337

add a commentÂ |Â

up vote
3
down vote

favorite

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

digraph reload_states 
 rankdir=LR;
 size="8,5"
 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" ];

Diagram

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

Store current state as enum and have method for each transition in the entity

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.

asked 4 hours ago

Evaldas Buinauskas

1337

add a commentÂ |Â

up vote
3
down vote

favorite

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

digraph reload_states 
 rankdir=LR;
 size="8,5"
 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" ];

Diagram

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

Store current state as enum and have method for each transition in the entity

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.

asked 4 hours ago

Evaldas Buinauskas

1337

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

digraph reload_states 
 rankdir=LR;
 size="8,5"
 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" ];

Diagram

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

Store current state as enum and have method for each transition in the entity

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.

design-patterns object-oriented-design domain-driven-design

asked 4 hours ago

Evaldas Buinauskas

1337

asked 4 hours ago

Evaldas Buinauskas

1337

asked 4 hours ago

Evaldas Buinauskas

1337

asked 4 hours ago

Evaldas Buinauskas

1337

asked 4 hours ago

Evaldas Buinauskas

1337

add a commentÂ |Â

1 Answer
1

active

oldest

votes

up vote
5
down vote

accepted

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.

answered 3 hours ago

Neil

17.5k3160

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.
â€“Â Evaldas Buinauskas
3 hours ago

@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
3 hours ago

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 :)
â€“Â Evaldas Buinauskas
3 hours ago

add a commentÂ |Â

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "131"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f378546%2fis-it-worth-considering-state-pattern-in-this-case%23new-answer', 'question_page');

);

Post as a guest

Name

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

up vote
5
down vote

accepted

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.

answered 3 hours ago

Neil

17.5k3160

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.
â€“Â Evaldas Buinauskas
3 hours ago

@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
3 hours ago

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 :)
â€“Â Evaldas Buinauskas
3 hours ago

add a commentÂ |Â

up vote
5
down vote

accepted

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.

answered 3 hours ago

Neil

17.5k3160

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.
â€“Â Evaldas Buinauskas
3 hours ago

@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
3 hours ago

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 :)
â€“Â Evaldas Buinauskas
3 hours ago

add a commentÂ |Â

up vote
5
down vote

accepted

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.

answered 3 hours ago

Neil

17.5k3160

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.

answered 3 hours ago

Neil

17.5k3160

answered 3 hours ago

Neil

17.5k3160

answered 3 hours ago

Neil

17.5k3160

answered 3 hours ago

Neil

17.5k3160

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.
â€“Â Evaldas Buinauskas
3 hours ago

@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
3 hours ago

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 :)
â€“Â Evaldas Buinauskas
3 hours ago

add a commentÂ |Â

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.
â€“Â Evaldas Buinauskas
3 hours ago

@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
3 hours ago

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 :)
â€“Â Evaldas Buinauskas
3 hours ago

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.
â€“Â Evaldas Buinauskas
3 hours ago

@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
3 hours ago

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 :)
â€“Â Evaldas Buinauskas
3 hours ago

add a commentÂ |Â

draft saved

draft discarded

draft saved

draft discarded

Post as a guest

Name

Search This Blog

Iyfjky