Какой-то поток сознания. Походу у Мура научился проблемы описывать.

Отделяем мух от котлет:

1) ООП нужно только если State это действительно (общее) состояние, которое надо соответственно моделировать типа счетчика событий. Эта задача не связана с другими.

2) Далее идет диспетчер, который также не связан с другими задачами.

3) И потом обработчики которые тоже реализуются независимо (либо как методы, либо как функции).

Ну и еще пару мыслей по поводу как это реализовать:

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

- Если State и Event оба просто данные, которые надо обрабатывать, тогда очевидно, что все симметрично. Состояния здесь нет.

- Если количество значений (State или Event) небольшое, то можно для каждого определить свой обработчик со своим именем, например, handler_Event25. Предпоалагается, что будущим поколениям не надо долго объяснять что делать.

- Диспетчер можно реализовать явно (switch),что хорошо (поскльку понятно другим), либо привинтить ОПП, где вызов виртуальных функций это и есть диспетчер, что плохо, поскольку люди потом должны догадываться, а нафига тут ООП с иерархией классов (подклассы будут иметь имена типа Subclass_State25, но все обработчики с одним именем).

- Если значения State и Event известны заранее, то можно все закодировать в код. Если нет, то можно динамически находить или подсасывать извне нужный код (и даже компилировать на ходу).