Entwurfsmuster für Verfolgung / Status - Entwurfsmuster, Verfolgung, Status

Was ist das engste Designmuster für einen Issue-Tracker?

Sie haben ein Objekt, das einen von verschiedenen Status haben kann: open, closed, in production.

Aktionen können basierend auf dem aktuellen Status ausgeführt werden.

Meine anfängliche Modellierung sieht ungefähr so ​​aus:

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

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

Mit der Möglichkeit, Aktionen zu gruppieren und die Gruppe einem Status zuzuordnen. Ähnlich wie die meisten Berechtigungsmodelle, die Sie sagen könnten.

War nur auf der Suche nach Input, welches Muster am meisten folgt, damit ich es noch etwas recherchieren kann. Vielen Dank!

Antworten:

Sie vertreten eine endliche Zustandsmaschine (FSM), wirklich ein Flussdiagramm, aber Ihr Klassendesign sieht aus wie ein doppelt verknüpfte Liste. Wenn Status den vorherigen und den nächsten Status bestimmtDies ist praktikabel, aber in den meisten Systemen ist dies unwahr. Betrachten Sie in Ihrem Beispiel den Status "offen". Kann es sein, dass der nächste "geschlossen" oder "in Produktion" ist?

Wenn beide Statusmöglichkeiten möglich sind, sollten Sie das Statusobjekt ändern und der Klassenhierarchie ein Transition-Objekt hinzufügen (oder möglicherweise das Action-Objekt ersetzen):

class Status
- transitions (Transition[])

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

Hier weiß Status, welche Übergänge möglich sind (z. B. kann "geöffnet" zu "geschlossen" oder "in Produktion" übergehen). Auf diese Weise repräsentieren Sie den FSM als gerichteter Graph. Nach meiner eigenen Erfahrung ist es in der Regel nicht wichtig, die Entität wissen zu lassen, woher sie gerade gekommen ist, also die Entfernung von prior_status. Stattdessen kann der Pfad durch die Protokollierung der Überwachungsprotokollierung / Datenbanktabelle erfasst werden.

Ich denke eine Kombination aus Zustand + Befehl