Шаблон проектирования для отслеживания / статусов

Question

Какой шаблон проектирования ближе всего подходит для средства отслеживания проблем?

У вас есть объект, который может иметь один из различных статусов: open, closed, in production.

Действия могут быть выполнены на основе текущего статуса.

Мое первоначальное моделирование выглядит примерно так:

class Status
    - next_status (None or Status)
    - previous_status (None or Status)
    - actions (set of Actions)

class Action
    - name (string)
    - description (string)

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

Просто искал информацию о том, какой шаблон наиболее подходит, чтобы я мог исследовать его еще немного.Спасибо!

Answer 1

Вы представляете конечный автомат (FSM), действительно блок-схему, но ваш дизайн класса выглядит как двусвязный список . Если Status определяет предыдущий и следующий статус, это работоспособно, но в большинстве систем это неверно. Рассмотрим статус «открыто» в вашем примере, возможно ли, что следующий может быть «закрыт» или «в производстве»?

Если оба статуса являются возможностями, рассмотрите возможность изменения объекта Status и добавления объекта Transition (или, возможно, замены Action?) В иерархию классов:

class Status 
    - transitions (Transition[])

class Transition 
    - from (Status)
    - to (Status)

Здесь Status знает, какие переходы возможны (например, «открыт» может переходить в «закрытый» или «в работе»). Таким образом, вы представляете FSM как направленный граф . Кроме того, по моему собственному опыту, обычно не важно, чтобы сущность знала, откуда она только что появилась, таким образом, удаление prior_status. Вместо этого путь может быть записан с помощью журнала аудита / истории захвата таблицы базы данных.

Answer 2

Я думаю, сочетание Состояние + Команда