Le macchine del mio stato possono utilizzare lo stato derivato dai dati del modello?

Question

Le macchine del mio stato possono utilizzare lo stato derivato dai dati del modello?

#1 da (1 voti)
#2 da (1 voti)

0

Sto mettendo insieme alcune idee e convenzioni personali su come configurare le macchine a stati quando si utilizza una libreria specifica per la lingua .

Poiché sto aggiungendo macchine di stato a classi di modelli esistenti nel mio progetto, alcuni degli stati che desidero sfruttare sono distribuiti nelle loro relazioni. Lo stato non è contenuto in un campo singolare, ma è invece informato da altre cose che accadono nel sistema che devo recuperare.

È normale / consentito all'implementazione di una macchina di stato l'origine dei dati dai relativi dati del modello? Oppure è un requisito irrinunciabile dell'implementazione di una macchina di stato che l'oggetto dominio con lo stato tracciato debba fornire un singolo campo per la struttura di stato da serializzare in?

(Si tratta invece di interpretare l'output della macchina di stato e di tradurlo in operazioni di modello come inserimenti, aggiornamenti e / o eliminazioni.)

finite-state-machine

posta Omega 11.06.2018 - 15:10

fonte

2 risposte

Leggi altre domande sui tag finite-state-machine

Quando utilizzare gli stub Gestione degli errori del server / dati del database durante l'elaborazione delle richieste dei client

score 1 · Answer 1

Una macchina a stati ha ingressi e uscite insieme a uno stato. Il modo in cui rappresenti tale stato dipende dalla tua implementazione.

Non è richiesto che uno stato venga mantenuto in un singolo campo. Ho spesso costruito macchine di stato composte da un numero di campi. Avrei un progetto di macchina statale che descrivesse le transizioni di stato. Per facilitare la comprensione, ad esempio, registrando le transizioni di stato, avrei una funzione che riporta lo stato dell'implementazione derivandolo dal valore composito dei campi.

score 1 · Answer 2

Non è necessario mantenere lo stato in un singolo campo, ma è molto più facile testare, verificare e in generale ragionare su una macchina a stati se è autonoma.

Lo stato di dispersione sparso in tutto il modello è quindi meno che ideale - a meno che non sia pratico, è preferibile mantenere lo stato pertinente all'interno della macchina (anche se questo richiede più campi).

Se non vedi questi campi secondari come parte dello stato di primo livello, è possibile

gestirli con una macchina a stati nidificati o con
trasmetterli alla macchina a stati come parametri di input aggiuntivi (in modo da distinguere efficacemente un tipo di evento a grana più fine).

Inoltre, su una nota del tutto indipendente, non stai facendo leva su qualcosa a meno che tu non abbia un fulcro, o qualche tipo di vantaggio meccanico metaforico. Senza quelli, stai solo usando.