1) Ответы на половину ваших вапросов есть в README. Если плохо знаете англицкий (хотя я писал на таком чукотском, что можно понять даже не зная), то вот:
State состояние, Transition тот же state, для перехода которому требуется Event - finish state. Пример использования:
У персонажа 2а состояния - ничего не делать и кипятить чайник. Для выполнения обоих нужно сделать переходное состояние - налить воду, вариант реализации:
Добавляем персонажу состояние наливания воды и соответствующий сигнал его начала и завершения.
Либо добавляем transition и просто говорим finish transition когда вода налита. Это сделано для того чтоб автомат не разростался и был менее разряжен чем мог бы быть.
т. е. ваш автомат асинхронный и выполняет переход как только появится входной сигнал.
Именно так. Состояние переходит из одного в другое в любой момент, если инициализирован соответствующий эвент. Выходной сигнал описывает функция делегат, на то она и передается в событие или переход.
Зачем нужны функции удаления состояний, переходов и вх. сигналов?
Маштабируемость. Если на написал автомат на 200 событий и тут мне потребовалась его реализация на такие же 180 - инициализировать заново?
Иначе может возникнуть неопределенное состояние вроде разбиения автомата на 2 несвязанных графа или отсутствие возможности попасть в какое-то состояние, куда можно было перейти только при возникновении удаленного события.
Пока да, это у меня в TODO (запрет разбитие на несвязанный граф)
Почему вы не решили описывать автомат матрицей переходов и матрицей выходных функций, а кол-во вх. сигналов, состояний и вых. сигналов указывать при создании автомата?
Какой именно матрицей? Инцидентности или смежности? Я знаю что граф обычно описывают ими, но для понимания логики они не очень удобны, как только у вас появляется более 20ти вершин графа. Напишите такую матрицу и потом посмотрите сколько времени у вас займет восстановление ее с ручкой и бумажкой в видел графа на бумаге.
Удобно наверное было бы сделать State отдельным объектом и хранить в каждом State структуру в которой хранился бы указатель на смежную вершину и указатель на функцию делегат (или сам делегат, я не знаю как это делает шарп, в плюсах точно был бы указатель), но я там наворотил бы ошибок которых правил бы еще месяц. И вообще стараюсь придерживатся правила не использовать ссылки и указатели без лишней надобности. Мб есть какой-то мизерный прирост памяти и скорости, но учитывая что это сделанно для игрового 3d движка, где почти все ресурсы сожрет графика - это похоже на идиотизм. Это примерно как если бы вы у плешивой собаки стали мыть лечебным шампунем только конец хвоста.
PS: Нотацию a->b украл у *.dot формата, уж больно понравилась.
LoadFromFile?
Если мне кто-то скажет, что можно как-то загрузить описание делегата из файла, я буду признателен. А то получится кучу состояний, которые ничего не делают и их все равно нужно потом инициализировать.
).
