Модел за проектиране за проследяване / състояния - дизайн-модели, проследяване, статус

Кой е най-близкият модел на дизайн за нещо като проблемно проследяване?

Имате обект, който може да бъде един от различни състояния: 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)

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

Просто търсех информация относно модела, който най-много следва, за да мога да го проуча още. Благодаря!

Отговори:

Ти представляваш машина с крайни състояния (FSM), наистина блок-схема, но дизайнът на вашия клас изглежда като двойно свързан списък, Ако Status определя предишния и следващия статустова е изпълним, но в повечето системи това е невярно. Помислете за състоянието на „отворен“ във вашия пример, възможно ли е следващото да бъде или „затворено“, или „в производство“?

Ако и двете състояния са възможности, обмислете промяна на обекта Status и добавяне на обект Transition (или може би заместване на Action?) Към вашата йерархия на класа:

class Status
- transitions (Transition[])

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

Тук Status знае за това какви преходи са възможни (например "отворен" може да премине към "затворен" или "в производство"). По този начин представяте FSM като a насочена графика, Също така, според моя опит обикновено не е важно да се знае, откъдето току-що е произлязло предприятието, така че отстраняването на prior_status, Вместо това пътят може да бъде уловен чрез регистрация на одит / таблица на базата данни, заснемаща историята.

Аз мисля комбинация от състояние + команда