Конечный автомат на основе перечисления Java (FSM): передача событий

Итак, вы хотите отправлять события их обработчикам для текущего состояния.

Для отправки в текущее состояние, подписка на каждое состояние, когда оно становится активным, и отмена подписки, когда оно становится неактивным, довольно обременительна. Легче подписаться на объект, который знает активное состояние и просто делегирует все события в активное состояние.

Чтобы различать события, вы можете использовать отдельные объекты событий, а затем различать их с помощью шаблона посетителя, но это довольно много шаблонного кода. Я бы сделал это только в том случае, если у меня есть другой код, который одинаково обрабатывает все события (например, если события должны быть помещены в буфер перед доставкой). В противном случае я бы просто сделал что-то вроде

interface StateEventListener {
    void onEventX();
    void onEventY(int x, int y);
    void onEventZ(String s);
}

enum State implements StateEventListener {
    initialState {
        @Override public void onEventX() {
            // do whatever
        }
        // same for other events
    },
    // same for other states
}

class StateMachine implements StateEventListener {
    State currentState;

    @Override public void onEventX() {
        currentState.onEventX();
    }

    @Override public void onEventY(int x, int y) {
        currentState.onEventY(x, y);
    }

    @Override public void onEventZ(String s) {
        currentState.onEventZ(s);
    }
}

Изменить

Если у вас много типов событий, возможно, лучше сгенерировать скучный код делегирования во время выполнения, используя библиотеку разработки байт-кода или даже простой прокси-сервер JDK:

class StateMachine2 {
    State currentState;

    final StateEventListener stateEventPublisher = buildStateEventForwarder(); 

    StateEventListener buildStateEventForwarder() {
        Class<?>[] interfaces = {StateEventListener.class};
        return (StateEventListener) Proxy.newProxyInstance(getClass().getClassLoader(), interfaces, new InvocationHandler() {
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                try {
                    return method.invoke(currentState, args);
                } catch (InvocationTargetException e) {
                    throw e.getCause();
                }
            }
        });
    }
}

Это делает код менее читаемым, но устраняет необходимость писать код делегирования для каждого типа события.

Почему бы событиям не вызывать правильный обратный вызов состояния напрямую?

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(); }
   }
   ...
}

Это устраняет обе ваши оговорки с использованием оригинального подхода: без «некрасивого» переключателя и без «неудобных» дополнительных параметров.

Вы на правильном пути, вам следует использовать шаблон стратегии в сочетании с вашим конечным автоматом. Реализуйте обработку событий в перечислении состояний, предоставив общую реализацию по умолчанию и, возможно, добавив конкретные реализации.

Определите свои события и связанный интерфейс стратегии:

enum Event
{
    EVENT_X,
    EVENT_Y,
    EVENT_Z;
    // Other events...
}

interface EventStrategy
{
    public void onEventX();
    public void onEventY();
    public void onEventZ();
    // Other events...
}

Затем в вашем State перечислении:

enum State implements EventStrategy
{
    STATE_A
    {
        @Override
        public void onEventX()
        {
            System.out.println("[STATE_A] Specific implementation for event X");
        }
    },

    STATE_B
    {
        @Override
        public void onEventY()
        {
            System.out.println("[STATE_B] Default implementation for event Y");     
        }

        public void onEventZ()
        {
            System.out.println("[STATE_B] Default implementation for event Z");
        }
    };
    // Other states...      

    public void process(Event e)
    {
        try
        {
            // Google Guava is used here
            Method listener = this.getClass().getMethod("on" + CaseFormat.UPPER_UNDERSCORE.to(CaseFormat.UPPER_CAMEL, e.name()));
            listener.invoke(this);
        }
        catch (Exception ex)
        {
            // Missing event handling or something went wrong
            throw new IllegalArgumentException("The event " + e.name() + " is not handled in the state machine", ex);
        }
    }

    // Default implementations

    public void onEventX()
    {
        System.out.println("Default implementation for event X");
    }

    public void onEventY()
    {
        System.out.println("Default implementation for event Y");       
    }

    public void onEventZ()
    {
        System.out.println("Default implementation for event Z");
    }
}

Согласно EventStrategy, для всех событий существует реализация по умолчанию. Более того, для каждого состояния возможна конкретная реализация для разной обработки событий.

StateMachine будет выглядеть так:

class StateMachine
{
    // Active state
    State mState;

    // All the code about state change

    public void onEvent(Event e)
    {
        mState.process(e);
    }
}

В этом сценарии вы доверяете mState как текущему активному состоянию, все события применяются только к этому состоянию. Если вы хотите добавить уровень безопасности, чтобы отключить все события для всех неактивных состояний, вы можете это сделать, но, на мой взгляд, это не очень хороший шаблон, State не должно знать, активен ли он, но это StateMachine работа.

Мне непонятно, зачем вам интерфейс обратного вызова, если у вас уже есть шина событий. Шина должна иметь возможность доставлять события слушателям в зависимости от типа события без необходимости в интерфейсах. Рассмотрим такую ​​архитектуру, как Guava (я знаю, что вы не хотите прибегать к внешним библиотекам , это дизайн, на что я хочу обратить ваше внимание).

enum State {
  S1 {
    @Subscribe void on(EventX ex) { ... }
  },
  S2 {
    @Subscribe void on(EventY ey) { ... }
  }
}

// when a state becomes active
eventBus.register(currentState);
eventBus.unregister(previousState);

Я считаю, что этот подход соответствует вашему первому комментарию к ответу Меритона:

Вместо того, чтобы вручную писать класс StateMachine для реализации тех же интерфейсов и делегирования событий в currentState, можно было бы автоматизировать это с помощью отражения (или чего-то еще). Затем внешний класс будет регистрироваться в качестве слушателя для этих классов во время выполнения и делегировать их, а также регистрировать / отменять регистрацию состояния при входе / выходе.

Вы можете попробовать использовать шаблон команды: интерфейс команды соответствует чему-то вроде вашего "ЧТО-ТО_СЛУЧИЛОСЬ" . Таким образом, каждое значение перечисления создается с помощью конкретной команды, которая может быть создана с помощью Reflection и может запускать метод выполнения (определенный в командном интерфейсе).

Если полезно, рассмотрите также шаблон состояния.

Если команды сложные, рассмотрите также составной шаблон.

Альтернативой для Java 8 может быть использование интерфейса с методами по умолчанию, например:

public interface IPositionFSM {

    default IPositionFSM processFoo() {
        return this;
    }

    default IPositionFSM processBar() {
        return this;
    }
}

public enum PositionFSM implements IPositionFSM {
    State1 {
        @Override
        public IPositionFSM processFoo() {
            return State2;
        }
    },
    State2 {
        @Override
        public IPositionFSM processBar() {
            return State1;
        }
    };
}

Как насчет реализации обработки событий с посетителями:

import java.util.LinkedHashMap;
import java.util.LinkedList;
import java.util.List;
import java.util.Map;

public class StateMachine {
    interface Visitor {
        void visited(State state);
    }

    enum State {
        // a to A, b to B
        A('a',"A",'b',"B"),
        // b to B, b is an end-state
        B('b',"B") {
            @Override
            public boolean endState() { return true; }
        },
        ;

        private final Map<Character,String> transitions = new LinkedHashMap<>();

        private State(Object...transitions) {
            for(int i=0;i<transitions.length;i+=2)
                this.transitions.put((Character) transitions[i], (String) transitions[i+1]);
        }
        private State transition(char c) {
            if(!transitions.containsKey(c))
                throw new IllegalStateException("no transition from "+this+" for "+c);
            return State.valueOf(transitions.get(c)).visit();
        }
        private State visit() {
            for(Visitor visitor : visitors)
                visitor.visited(this);
            return this;
        }
        public boolean endState() { return false; }
        private final List<Visitor> visitors = new LinkedList<>();
        public final void addVisitor(Visitor visitor) {
            visitors.add(visitor);
        }
        public State process(String input) {
            State state = this;
            for(char c : input.toCharArray())
                state = state.transition(c);
            return state;
        } 
    }

    public static void main(String args[]) {
        String input = "aabbbb";

        Visitor commonVisitor = new Visitor() {
            @Override
            public void visited(State state) {
                System.out.println("visited "+state);
            }
        };

        State.A.addVisitor(commonVisitor);
        State.B.addVisitor(commonVisitor);

        State state = State.A.process(input);

        System.out.println("endState = "+state.endState());
    }
}

На мой взгляд, определение диаграммы состояний и код обработки событий выглядят довольно минималистично. :) И, приложив немного больше усилий, его можно заставить работать с общим типом ввода.

Простой пример, если у вас нет событий, и вам просто нужен следующий общедоступный список со статусом LeaveRequestState {

    Submitted {
        @Override
        public LeaveRequestState nextState() {
            return Escalated;
        }

        @Override
        public String responsiblePerson() {
            return "Employee";
        }
    },
    Escalated {
        @Override
        public LeaveRequestState nextState() {
            return Approved;
        }

        @Override
        public String responsiblePerson() {
            return "Team Leader";
        }
    },
    Approved {
        @Override
        public LeaveRequestState nextState() {
            return this;
        }

        @Override
        public String responsiblePerson() {
            return "Department Manager";
        }
    };

    public abstract LeaveRequestState nextState(); 
    public abstract String responsiblePerson();
}