Is it ok to implement State pattern here?

Question

Hello,

I have a Request class that can be in one of the following states:

Draft, Submitted, Approved, Rejected, InMission, Completed

The state of the Request object can be changed by calling one of the following methods. Each method may include some arguments to further associate some data with a particular state:

void Submit(string by) { }
void Approve(string by, string comment) { }
void Reject(string by, string comment) { } 
void AddToMission(Mission mission) { } 
void Complete() { }

I was thinking of implementing the State pattern here. Each of my state classes will hold those extra information associated with them. My main idea to implement State pattern here is to not add all these unreleated properties in the Request class itself, like:

public string ApprovedBy;
public string ApprovedComment;
public string RejectedBy;
public string RejectedComment;
public Mission Mission; 

Do you think State pattern is a good candidate to implement here?

Regards,

Mosh

Answer 1

The state pattern has the advantage that you can not call Complete() on a Draft, because it simply does not have that method. However, it seems you want a more complex class structure.

• Submitted is a Draft
• Approved is a Submitted
• Rejected is a Submitted
• Completed is a Approved

So you would get more like a deep tree than all these implementing some Document interface.

Think good about if you want this, because nesting classes more than 3 levels is a pain to work with. A solution could be to make only two or three real types, and store some states in a property field. The Draft would then for example have a property Rejected or Status.

An alternative is to use the Decorator pattern. That is, if the document is approved, you construct a new Approved and pass the Draft to the constructor. This way, you do not get the deep inheritance and you can still get information from the Draft.

Answer 2

As far As I understood your problem is to transfer vary information between classes?

you may group all those info in a struct or class and transfer it as an agrument of abstract Request method. so each derived class (Draft, Submitted, Approved) may pick up needed info from this struct or set it. Moveover you can unify this info like this:

struct Info{
public string Status; // may be aproved  reqested or so.
public string Comment; // just a comment depending on state
//public string RejectedBy;
//public string RejectedComment; no need it
public Mission Mission; //extra info

}