Utilizzo delle macchine a stati durante la gestione delle risorse remote

Question

Utilizzo delle macchine a stati durante la gestione delle risorse remote

#1 da (1 voti)

2

Quindi ho un servizio che sto cercando di ripulire. Risponde alle richieste avviando un server arrestato su Amazon EC2, aspettando che arrivi in linea, quindi configura un software di terze parti sul server tramite una pausa API e quindi imposta un'attività da avviare su quella parte di software di terze parti . Il servizio esegue anche alcune operazioni di tipo di manutenzione e tenta di tenere traccia dei server o dei server "orfani" che non devono più essere in esecuzione e chiuderli. Attualmente mantiene lo stato in un database.

In questo momento funziona come una macchina statale informale. Il "compito" è l'unità che viene gestita, e l'attività ha tutti i tipi di stati in cui può essere, ma fondamentalmente la maggior parte degli stati sono solo passi nel processo di inizializzazione. Il codice è piuttosto disordinato e l'aggiunta di funzionalità può essere alquanto dolorosa. Ad esempio, sto cercando di trovare un modo per annullare l'attività mentre il processo di inizializzazione è in corso senza scrivere nei controlli manuali per vedere se è stato cancellato all'inizio di ogni passaggio.

Ho pensato che una macchina a stati sarebbe un buon modo per ripulire tutto e standardizzare il codice, ma sembra che ci sia un problema con quella soluzione quando la considero più attentamente. In una macchina a stati, controlli direttamente lo stato e definisci le transizioni tra stati che dovrebbero essere possibili. In questo sistema, però, utilizzo davvero l'API AWS e questa API software di terze parti per dirmi qual è lo stato delle cose. Indipendentemente da ciò che il mio servizio pensa che lo stato dovrebbe essere, la vera fonte della verità è al di fuori del mio controllo, e devo passare a qualsiasi stato mi dica che è dentro e lavorare da lì. Quindi sembra che finirò per creare una macchina a stati solo per rompere fondamentalmente tutte le sue regole e controllare manualmente lo stato comunque.

Una macchina a stati è inadatta per questo? C'è un altro modello che dovrebbe funzionare meglio? O devo solo lavorare lentamente sul refactoring per renderlo migliore.

design-patterns finite-state-machine

posta Frogglet 21.03.2018 - 21:06

fonte

1 risposta

Leggi altre domande sui tag design-patterns finite-state-machine

Test su ciascun endpoint di autorizzazione? Come implementare il modello di strategia per i comportamenti combinati

score 1 · Accepted Answer

Una macchina a stati può effettivamente funzionare bene, a condizione che tu divida il controllo della macchina a stati dalla macchina a stati stessa e le definizioni su come passare da uno stato a un altro.

Supponiamo di aver creato una macchina di stato chiamata StateMachine e di aver dato tre stati, State1, State2 e State3. Potresti avere qualcosa come il seguente pseudo-pseudo-codice:

class StateMachine{
    abstract class BaseState{}
    class State1 extends BaseState{}
    class State2 extends BaseState{}
    class State3 extends BaseState{}

    BaseState state;

    void moveToState2(){
        if(state is State1){
            //logic to get variables to pass into State2's ctor, possibly from State1 and/or from input parameters
            state = new State2();
        }
        else if(state is State3){
            //logic to get variables to pass into State2's ctor, possibly from State3 and/or from input parameters
            state = new State2();
        }
        //already in State2! Yay!
    }
    void moveToState3(){
        if(state is State2){
            //logic to get variables to pass into State3's ctor, possibly from State2 and/or from input parameters
            state = new State3();
        }
        else if(state is State1){
            //logic to get variables to pass into State3's ctor, possibly from State1 and/or from input parameters
            state = new State3();
        }
        //already in State3! Yay!
    }
    void moveToState1(){
        if(state is State3){
            //logic to get variables to pass into State1's ctor, possibly from State3 and/or from input parameters
            state = new State1();
        }
        else if(state is State2){
            //logic to get variables to pass into State1's ctor, possibly from State2 and/or from input parameters
            state = new State1();
        }
        //already in State1! Yay!
    }
}

Quindi, la macchina di stato mantiene il suo stato e tutte le variabili appropriate necessarie per ogni stato e sa anche come passare da uno stato all'altro, ma non controlla il proprio flusso; questo viene fatto dall'esterno. E se è possibile, magari aggiungere uno stato di errore e passare a quello su richieste di transizione state non valide. Oppure registrati, o qualsiasi altra cosa.

Fondamentalmente, le macchine di stato non hanno bisogno di decidere il proprio flusso. Tendono a, ma possono anche solo definire gli stati e le transizioni.