基于 Java 枚举的状态机 (FSM) : Passing in events

Question

我在我的 Android 应用程序中使用了几个基于枚举的状态机。虽然这些工作得很好，但我正在寻找的是关于如何优雅地接收事件的建议，通常来自注册的回调或事件总线消息，进入当前 Activity 状态。在许多关于基于枚举的 FSM 的博客和教程中，大多数都提供了使用数据的状态机(例如解析器)的示例，而不是展示如何从事件驱动这些 FSM。

我使用的典型状态机具有这种形式:

private State mState;

public enum State {

    SOME_STATE {


        init() {
         ... 
        }


        process() {
         ... 
        }


    },


    ANOTHER_STATE {

        init() {
         ... 
        }

        process() {
         ... 
        }

    }

}

...

在我的情况下，某些状态会触发对特定对象完成的一项工作，即注册一个监听器。该对象在工作完成时异步回调。也就是说，只是一个简单的回调接口(interface)。

同样，我有一个 EventBus。希望再次收到事件通知的类在 EventBus 上为这些事件类型实现回调接口(interface)和 listen()。

因此，基本问题是状态机，或者它的各个状态，或者包含枚举 FSM 的类，或者 something 必须实现那些回调接口(interface)，以便它们可以表示事件当前状态。

我使用的一种方法是让整个 enum 实现回调接口(interface)。枚举本身在底部有回调方法的默认实现，然后各个状态可以覆盖他们感兴趣的事件的回调方法。为此，每个状态必须在进入和退出时注册和取消注册，否则在不是当前状态的状态上存在回调发生的风险。如果我没有找到更好的选择，我可能会坚持下去。

另一种方法是让包含类实现回调。然后它必须通过调用 mState.process(event) 将这些事件委托(delegate)给状态机。这意味着我需要枚举事件类型。例如:

enum Events {
    SOMETHING_HAPPENED,
    ...
}

...

onSometingHappened() {

    mState.process( SOMETHING_HAPPENED );
}

但我不喜欢这样，因为 (a) 我需要在每个的 process(event) 中的事件类型上 switch状态，并且 (b) 传递额外的参数看起来很尴尬。

我想要一个优雅的解决方案的建议，而无需使用库。

Answer 1

为什么不让事件直接在状态上调用正确的回调？

public enum State {
   abstract State processFoo();
   abstract State processBar();
   State processBat() { return this; } // A default implementation, so that states that do not use this event do not have to implement it anyway.
   ...
   State1 {
     State processFoo() { return State2; }
     ...
   },
   State2 {
      State processFoo() { return State1; }
      ...
   } 
}

public enum  Event {
   abstract State dispatch(State state);
   Foo {
      State dispatch(State s) { return s.processFoo(); }
   },
   Bar {
      State dispatch(State s) { return s.processBar(); }
   }
   ...
}

这解决了您对原始方法的保留意见:没有“丑陋”的开关，也没有“尴尬”的附加参数。