Я какое-то время баловался в Скале, изучал Акку издалека и, наконец, погрузился. Черта FSM закрыла для меня сделку. Что меня беспокоит, так это то, что я мог понять, каким образом данные будут передаваться не по назначению, и я мог неправильно представить цикл обработки событий, чтобы соответствовать рекомендациям Akka.
В моей задаче у меня есть центральный координатор, который будет сопоставлять входящие запросы задач с соответствующими действующими лицами, которые также являются конечными автоматами. Первоначально я предполагал, что onTransition даст не только название штата, но и данные о состоянии.
Я полагаю, что традиционная инкапсуляция данных была бы причиной не показывать эти данные слушателям. Но для меня у меня есть два варианта использования этих данных другими.
Данные состояния содержат базовый объект домена, свойства которого используются для определения, какие субъекты являются наилучшим кандидатом для выполнения задания с учетом его требований. Поскольку требования к работе являются динамическими, я не решаюсь иметь отдельные коллекции рабочих актеров (хотя я не уверен, почему это должно дать мне паузу).
Идея опроса всех отдельных действующих лиц, отвечающих другим предварительным условиям, и присоединения ко всем их ответам кажется неэффективной или, по крайней мере, не идиоматичной для Акки. Мне также необходимо отобразить в пользовательском интерфейсе текущее состояние и не видеть причин, по которым следует использовать ту же очередь событий для просмотра состояния.
Во всяком случае, я подумывал о том, чтобы FSM обновил агента, но, поскольку это сам актер, я не уверен, что этот уровень косвенности покупает меня, и это может усложнить рассуждение о последовательности событий.
Сотрудничество Фаулера по событиям указывает мне на явную отправку данных о состоянии, но я надеялся на более простой способ сделать это для всех переходов, которые автоматически обновляют данные о состоянии.
Мне также трудно обернуть голову вокруг последовательности каскадов событий, и нужно ли мне это контролировать. Даже если все мои входящие внешние события проходят через одного актера, я хочу обработать все внутренне сгенерированные события всем остальным акторам перед обработкой следующего внешнего события. Я думал о том, чтобы использовать центральный координатор !! ждать ответа, но меня беспокоит, что если случайно удалить один восклицательный знак где-то в цепочке событий, я потеряю эту гарантию.
Решения, которые я рассматриваю для этой проблемы, включают использование приоритетных событий, так что внутренним событиям присваивается более высокий приоритет, использование однопоточного диспетчера (может быть, с кражей работы?) Для всех «внутренних» акторов, которые совместно используются.
Существуют ли передовые практики для того, что я пытаюсь сделать, или я пытаюсь сделать не то, что нужно :)?