0

我正在设计一个游戏，它会通过一些状态进行转换，我已经看到使用了两种模式，一种如下：

1）枚举模式，其中：

static {
    // standard states
    transitions.put(PHASE 1, new State[]{PHASE2, PHASE3, PHASE4});

2）类中的状态模式，你有一个抽象，以及扩展抽象并代表每个状态的子类......单态模式？

我在两者之间有点纠结，看起来都是很好的解决方案，对于游戏来说，什么更干净更容易理解？

我个人喜欢单态，但枚举方法似乎是这样。

4

3 回答 3

2

至于“更清洁的代码”，这是一个选择问题。

一些需要考虑的事情

如果添加另一个状态和 N 个转换，代码会发生什么情况？您和团队中的其他开发人员仍然可以阅读它吗？尝试达成某种共识，或者将其体现在代码风格指南中。

恕我直言，由于您使用的语言是面向对象的，因此我将使用 GOF 书中的状态模式，因为它利用了封装和多态性。

如果您用“C”编写它，我会选择表驱动的方法。

于 2012-10-10T10:05:41.983 回答
1

这取决于您是否需要在状态中存储任何业务逻辑。第二种选择可能会使这更容易。你所有的州都可以实现类似的东西：

interface State {
    State transition(Event event);
}

然后您可以拥有一种管理器类来管理转换：

class StateManager {
    State actualState = new BaseState();
    void processEvent(Event event) {
        actualState = actualState.transition(event);
    }
}

然后您的实现State根据输入选择并返回下一个状态应该是什么。

你基本上是在实现一个有限状态机。

如果您的机器可能很快变得复杂，您应该像@duffymo 所说的那样，将转换外部化。我敢肯定那里有图书馆可以做到这一点，尽管我不知道任何名称。

于 2012-10-10T10:05:25.923 回答
0

我都不推荐。编写一个有限状态机并将状态和转换外部化为 XML 或 JSON。这将是一个更加灵活的设计。

于 2012-10-10T10:01:23.980 回答