Синхронизация двух конечных автоматов

Question

Скажем, я создаю приложение для управления бизнес-процессами. Он имеет следующие сущности: проблемы и задачи, связанные друг с другом как одна проблема для многих задач. И задача, и задача имеют свои собственные состояния, и состояние одного может влиять на состояние другого.

Например, оба имеют состояния «Отменено» и «Завершено». Когда я изменяю состояние вопроса на «Отменено», все его задачи должны стать «Отменено». Когда я изменяю состояние всех задач на «Завершено», проблема должна автоматически становиться «Завершена».

Предположим, что для обеих сущностей существует довольно много состояний, и логика переходов из одного состояния в другое и зависимость состояний может измениться. Существуют ли какие-либо шаблоны проектирования и / или лучшие практики для решения этой ситуации?

Answer 1

Я предпочитаю шаблон наблюдателя для такого рода вещей: http://en.wikipedia.org/wiki/Observer_pattern В приведенном вами примере у меня будут задачи наблюдать за их проблемой, а проблемы - за их задачами. Когда проблема помечена как отмененная, задачи видят и отмечают себя отмененными. Когда задача помечена как выполненная, проблема видит ее и проверяет, выполнены ли другие задачи и т. Д.

Answer 2

Шаблон проектирования, который приходит на ум, является «правилом»; -)

Или, если хотите, шаблон команды

Другими словами, для подобных ситуаций я бы создал таблицу базы данных, в которой перечислены состояния и допустимые переходы, и связывал действие с каждым переходом (используя отражение)

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

Например, в одной системе у нас был рабочий процесс, в котором документ запроса должен был проходить через несколько станций проверки комитетов, каждая из которых могла отклонить или передать документ на следующую стадию, плюс пользовательская обработка побочных эффектов. Организация комитета, структуры обработки и действия по обработке существенно изменились три раза во время разработки и еще пять раз за первый год развертывания.