【发布时间】:2022-11-17 18:46:43
【问题描述】:
在经典版本的状态中,每个状态都实现了一些接口。所以我们可以将执行传递给任何当前状态
class Context
{
private State _state;
public void MethodA()
{
_state.MethodA();
}
public void MethodB()
{
_state.MethodB();
}
}
但就我而言。我有一个游戏功能。它提供了可以购买的东西。它也有状态,如“活动”、“购买”、“准备”、“完成”等。他们中的一些人允许购买,而其他人则不允许。 以更抽象的方式——每个状态只实现上下文接口方法的一部分。和方法可能相交
class ConcreteStateA
{
public void MethodA()
{
// Do A
}
// No MethodB
}
class ConcreteStateB
{
// No MethodA
public void MethodB()
{
// Do B
}
}
问题:以这种方式使用状态机是否有任何修改?当前的变化导致在调用上下文之前直接检查它是否是正确的状态。状态类层次结构不能避免状态类型检查的问题
【问题讨论】:
-
Is there a typical state machine implementation pattern? 中似乎有一些很好的答案。另请注意:有一个difference between a state machine and the state pattern。在该模式中,状态必须是多态的:每个状态都呈现相同的 API。在机器中,转换到新状态会导致一组新操作。因此,该模式侧重于设计行为内状态,而机器专注于设计转换之间状态。
标签: c# unity3d design-patterns state state-machine