在这里实现状态模式可以吗？
我有一个 Request 类，可以处于以下状态之一：
草稿， 已提交， 得到正式认可的， 被拒绝， 在任务中， 已完成
可以通过调用以下方法之一来更改 Request 对象的状态。每个方法可能包含一些参数，以进一步将某些数据与特定状态相关联：
void Submit(string by) { }
void Approve(string by, string comment) { }
void Reject(string by, string comment) { }
void AddToMission(Mission mission) { }
void Complete() { }
我正在考虑在这里实现状态模式。我的每个状态类都将保存与它们相关的额外信息。我在这里实现 State 模式的主要想法是不要在 Request 类本身中添加所有这些不相关的属性，例如：
public string ApprovedBy;
public string ApprovedComment;
public string RejectedBy;
public string RejectedComment;
public Mission Mission;
您认为 State 模式吗是在这里实施的好候选人吗？
问候，
莫什
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
状态模式的优点是您无法在草稿上调用
Complete()，因为它根本没有该方法。但是，您似乎想要一个更复杂的类结构。，因此您会得到比所有这些实现某些文档接口的更深层次的树。
如果您想要这样做，请好好考虑一下，因为超过 3 层的嵌套类使用起来很痛苦。解决方案可能是仅创建两个或三个实际类型，并将一些状态存储在属性字段中。例如，草稿将具有“已拒绝”或“状态”属性。
另一种方法是使用装饰器模式。也就是说，如果文档获得批准，您将构造一个新的 Approved 并将 Draft 传递给构造函数。这样，您就不会获得深层继承，并且仍然可以从草案中获取信息。
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.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.
据我了解，您的问题是在类之间传输不同的信息？
您可以将所有这些信息分组到一个结构或类中，并将其作为抽象 Request 方法的参数进行传输。
因此每个派生类（草稿、已提交、已批准）都可以从此结构中获取或设置所需的信息。
此外，您可以像这样统一这些信息：
}
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:
}