Stato. Classi statali per ogni stato

Naturalmente, questo non è l’unico modo per implementare la gerarchia. Ma se non usi il modello Gang of Four State, non funzionerà. Invece, puoi modellare una chiara gerarchia degli stati attuali e dei superstati con pila stati invece di un singolo stato nella classe principale.

Lo stato attuale sarà in cima allo stack, sotto c'è il suo superstato, quindi il superstato per Questo superstati, ecc. E quando è necessario implementare un comportamento specifico dello stato, si inizia dalla cima dello stack e si procede verso il basso finché lo stato non lo gestisce. (E se non lo elabora, semplicemente lo ignori).

Macchina automatica con memoria magazzino

Esiste un'altra estensione comune alle macchine a stati che utilizza anch'essa uno stack di stati. Solo che qui lo stack rappresenta un concetto completamente diverso e viene utilizzato per risolvere problemi diversi.

Il problema è che una macchina statale non ha concetto storie. Sai in che stato ti trovi? sei, ma non hai informazioni sullo stato in cui ti trovi erano. E di conseguenza, non esiste un modo semplice per tornare allo stato precedente.

Ecco un semplice esempio: in precedenza, permettevamo alla nostra impavida eroina di armarsi fino ai denti. Quando spara con la sua arma, abbiamo bisogno di un nuovo stato per riprodurre l'animazione dello sparo, generare il proiettile e gli effetti visivi di accompagnamento. Per fare ciò, creiamo un nuovo FiringState ed effettuiamo transizioni verso di esso da tutti gli stati in cui l'eroina può sparare premendo il pulsante di fuoco.

Poiché questo comportamento è duplicato tra più stati, è qui che è possibile utilizzare una macchina a stati gerarchica per riutilizzare il codice.

La difficoltà qui è che devi in ​​qualche modo capire in quale stato devi andare. Dopo tiro. L'eroina può sparare l'intera clip mentre è ferma, corre, salta o accovacciata. Una volta terminata la sequenza delle riprese, deve tornare allo stato in cui si trovava prima delle riprese.

Se ci affezioniamo alla FSM pura, dimentichiamo immediatamente in quale stato ci trovavamo. Per tenerne traccia, dobbiamo definire molti stati quasi identici: tiro da fermo, tiro in corsa, tiro in salto, ecc. Pertanto, abbiamo transizioni codificate che passano allo stato corretto una volta completate.

Ciò di cui abbiamo veramente bisogno è la capacità di memorizzare lo stato in cui ci trovavamo prima della sparatoria e di ricordarlo nuovamente dopo la sparatoria. Anche in questo caso la teoria degli automi ci viene in aiuto. La struttura dati corrispondente si chiama Pushdown Automaton.

Laddove in un automa finito abbiamo un singolo puntatore allo stato, in un automa con memoria di deposito c'è il loro pila. Nella FSM, la transizione verso un nuovo stato sostituisce quello precedente. Anche una macchina dotata di memoria magazzino consente di farlo, ma aggiunge altre due operazioni:

Puoi posto (spingere) nuovo stato nello stack. Lo stato corrente sarà sempre in cima allo stack, quindi questa è l'operazione di passaggio a un nuovo stato. Ma allo stesso tempo, il vecchio stato rimane direttamente sotto quello attuale nello stack e non scompare senza lasciare traccia.

Puoi estratto (pop) stato in cima allo stack. Lo Stato scompare e ciò che c'era sotto diventa attuale.

Questo è tutto ciò di cui abbiamo bisogno per le riprese. Noi creiamo l'unica cosa condizione di ripresa. Quando premiamo il pulsante di fuoco mentre ci troviamo in uno stato diverso, noi posto (spingere) stato di ripresa dello stack. Al termine dell'animazione delle riprese, noi estratto (pop) e una macchina con memoria magazzino ci riporta automaticamente allo stato precedente.

Quanto sono davvero utili?

Anche con questa espansione delle macchine statali, le loro capacità sono ancora piuttosto limitate. Nell'intelligenza artificiale odierna, la tendenza prevalente è quella di utilizzare cose come alberi comportamentali(alberi comportamentali) e sistemi di pianificazione(sistemi di pianificazione). E se sei particolarmente interessato al campo dell'intelligenza artificiale, l'intero capitolo dovrebbe stuzzicare il tuo appetito. Per soddisfarlo, dovrai rivolgerti ad altri libri.

Ciò non significa affatto che le macchine a stati finiti, le macchine con memoria di magazzino e altri sistemi simili siano completamente inutili. Per alcune cose questi sono buoni strumenti di modellazione. Le macchine a stati sono utili quando:

• Hai un'entità il cui comportamento cambia a seconda del suo stato interno.
• Questa condizione è rigorosamente suddivisa in un numero relativamente piccolo di opzioni specifiche.
• L'entità risponde continuamente a una serie di comandi o eventi di input.

Nei giochi, le macchine a stati vengono generalmente utilizzate per modellare l'intelligenza artificiale, ma possono anche essere utilizzate per implementare l'input dell'utente, la navigazione nei menu, l'analisi del testo, i protocolli di rete e altri comportamenti asincroni.

Lo stato è un modello di comportamento dell'oggetto che specifica funzionalità diverse a seconda dello stato interno dell'oggetto. fonte del sito web originale

Condizioni, compito, scopo

Motivazione

L'idea principale di questo modello è introdurre una classe astratta TCPState per rappresentare diversi stati di connessione. Questa classe dichiara un'interfaccia comune a tutte le classi che descrivono diversi lavoratori. fonte originale.ru

condizione. In queste sottoclassi TCPState viene implementato il comportamento specifico dello stato. Ad esempio, nelle classi TCPstabilito E TCPChiuso comportamento specifico dello stato implementato Stabilito E Chiuso rispettivamente. fonte originale del sito web del sito web

originale.ru

Classe Connessione TCP memorizza un oggetto di stato (un'istanza di una sottoclasse TCPState) che rappresenta lo stato corrente della connessione e delega tutte le richieste dipendenti dallo stato a questo oggetto. Connessione TCP utilizza la propria istanza della sottoclasse TCPState abbastanza semplice: chiamare metodi di una singola interfaccia TCPState, solo a seconda della sottoclasse specifica attualmente memorizzata TCPState-a - il risultato è diverso, cioè in realtà vengono eseguite operazioni specifiche solo per questo stato di connessione. fonte originale.ru

E ogni volta che cambia lo stato della connessioneConnessione TCP cambia il suo oggetto di stato. Ad esempio, quando una connessione stabilita viene chiusa, Connessione TCP sostituisce un'istanza di una classe TCPstabilito copia TCPChiuso. sito sito di origine originale

Segni di applicazione, uso del modello di Stato

1. Quando il comportamento di un oggetto dipende dal suo stato e deve cambiare in fase di esecuzione. fonte originale.ru
2. Quando il codice dell'operazione contiene istruzioni condizionali costituite da molti rami, in cui la scelta del ramo dipende dallo stato. Tipicamente in questo caso lo stato è rappresentato da costanti enumerate. Spesso la stessa struttura dell'istruzione condizionale viene ripetuta in diverse operazioni. Lo schema dello stato suggerisce di collocare ciascun ramo in una classe separata. Ciò consente di trattare lo stato di un oggetto come un oggetto indipendente che può cambiare indipendentemente dagli altri. sito sorgente sito originale

Soluzione

source.ru

Partecipanti al modello statale

1. Contesto(Connessione TCP) - contesto.
   Definisce un'unica interfaccia per i client.
   Memorizza un'istanza di una sottoclasse StatoConcreto, che determina lo stato attuale. codelab.
2. Stato(TCPState) - stato.
   Definisce un'interfaccia per incapsulare il comportamento associato a un particolare stato del contesto. sito di origine sito originale
3. Sottoclassi StatoConcreto(TCPEstablished, TCPListen, TCPClosed) - stato specifico.
   Ogni sottoclasse implementa il comportamento associato ad alcuni stati del contesto Contesto. sito sito di origine originale

Schema per l'utilizzo del modello di Stato

Un contesto può passare se stesso come argomento a un oggetto Stato, che elaborerà la richiesta. Ciò consente all'oggetto stato ( StatoConcreto) accedere al contesto se necessario. codelab.

Contesto- Questa è l'interfaccia principale per i client. I client possono configurare il contesto con oggetti di stato Stato(più precisamente StatoConcreto). Una volta configurato il contesto, i client non hanno più bisogno di comunicare direttamente con gli oggetti di stato (solo attraverso l'interfaccia comune Stato). source.ru

Anche in questo caso Contesto o le sottoclassi stesse StatoConcreto può decidere in quali condizioni e in quale ordine avviene il cambiamento di stato. fonte del sito web originale

Domande riguardanti l'attuazione del modello Stato

1. Cosa determina le transizioni tra stati.
   Il modello statale non dice nulla su quale partecipante determini le condizioni (criteri) per la transizione tra stati. Se i criteri sono fissi, possono essere implementati direttamente nella classe Contesto. Tuttavia, in generale, un approccio più flessibile e corretto è quello di consentire le sottoclassi della classe stessa Stato determinare lo stato successivo e il momento di transizione. Per farlo in classe Contesto dobbiamo aggiungere un'interfaccia che consenta dagli oggetti Stato impostarne lo stato.
   Questa logica di transizione decentralizzata è più facile da modificare ed estendere: devi solo definire nuove sottoclassi Stato. Lo svantaggio del decentramento è che ogni sottoclasse Stato deve “conoscere” almeno una sottoclasse di un altro stato (al quale può effettivamente passare allo stato corrente), il che introduce dipendenze di implementazione tra le sottoclassi. sito di origine sito originale

   fonte originale.ru

2. Alternativa tabellare.
   Esiste un altro modo per strutturare il codice guidato dallo stato. Questo è il principio di una macchina a stati finiti. Utilizza una tabella per mappare gli input alle transizioni di stato. Con il suo aiuto, puoi determinare in quale stato devi andare quando arrivano determinati dati di input. In sostanza, stiamo sostituendo il codice condizionale con una ricerca nella tabella.
   Il vantaggio principale della macchina è la sua regolarità: per cambiare i criteri di transizione è sufficiente modificare solo i dati, non il codice. Ma ci sono anche degli svantaggi:
   - cercare una tabella è spesso meno efficiente che chiamare una funzione,
   - presentare la logica di transizione in un formato tabellare uniforme rende i criteri meno espliciti e, quindi, più difficili da comprendere,
   - solitamente è difficile aggiungere azioni che accompagnino le transizioni tra Stati. Il metodo tabellare tiene conto degli stati e delle transizioni tra di essi, ma deve essere integrato in modo che possano essere eseguiti calcoli arbitrari ad ogni cambiamento di stato.
   La differenza principale tra le macchine a stati basate su tabelle e Pattern State può essere formulata come segue: Pattern State modella il comportamento dipendente dallo stato e il metodo della tabella si concentra sulla definizione delle transizioni tra gli stati. originale.ru

   sito sito di origine originale

3. Creazione e distruzione di oggetti statali.
   Durante il processo di sviluppo solitamente devi scegliere tra:
   - creare oggetti statali quando sono necessari e distruggerli immediatamente dopo l'uso,
   -creandoli in anticipo e per sempre.

   La prima opzione è preferibile quando non si sa in anticipo in quali stati cadrà il sistema e il contesto cambia lo stato relativamente raramente. Allo stesso tempo, non creiamo oggetti che non verranno mai utilizzati, il che è importante se negli oggetti di stato vengono archiviate molte informazioni. Quando i cambiamenti di stato si verificano frequentemente, quindi non vuoi distruggere gli oggetti che li rappresentano (perché potrebbero essere nuovamente necessari molto presto), dovresti usare il secondo approccio. Il tempo per la creazione degli oggetti viene speso solo una volta, all'inizio, e il tempo per la distruzione non viene speso affatto. È vero, questo approccio può rivelarsi scomodo, poiché il contesto deve memorizzare riferimenti a tutti gli stati in cui teoricamente il sistema potrebbe cadere. fonte originale.ru

   source.ru originale

4. Utilizzando il cambiamento dinamico.
   È possibile variare il comportamento su richiesta modificando la classe dell'oggetto in fase di esecuzione, ma la maggior parte dei linguaggi orientati agli oggetti non lo supporta. L'eccezione è rappresentata da Perl, JavaScript e altri linguaggi basati su motori di scripting che forniscono tale meccanismo e quindi supportano direttamente Pattern State. Ciò consente agli oggetti di variare il proprio comportamento modificando il codice della classe. source.ru

   .ru fonte originale

risultati

1. Localizza il comportamento dipendente dallo stato.
   E lo divide in parti corrispondenti agli stati. Il modello di stato inserisce tutto il comportamento associato a un particolare stato in un oggetto separato. Perché il codice dipendente dallo stato è interamente contenuto in una delle sottoclassi della classe Stato, quindi puoi aggiungere nuovi stati e transizioni semplicemente generando nuove sottoclassi.
   Invece, si potrebbero usare i membri dati per definire gli stati interni, quindi le operazioni dell'oggetto Contesto controllerei questi dati. Ma in questo caso, istruzioni condizionali o istruzioni di ramo simili sarebbero sparse in tutto il codice della classe Contesto. Tuttavia, l'aggiunta di un nuovo stato richiederebbe la modifica di diverse operazioni, il che renderebbe difficile la manutenzione. Il modello di stato risolve questo problema, ma ne crea anche un altro, poiché il comportamento per i diversi stati finisce per essere distribuito tra diverse sottoclassi Stato. Ciò aumenta il numero di classi. Naturalmente, una classe è più compatta, ma se ci sono molti stati, allora tale distribuzione è più efficiente, poiché altrimenti bisognerebbe fare i conti con istruzioni condizionali ingombranti.
   Avere istruzioni condizionali complicate non è auspicabile, così come avere procedure lunghe. Sono troppo monolitici, motivo per cui modificare ed estendere il codice diventa un problema. Il modello di stato offre un modo migliore per strutturare il codice dipendente dallo stato. La logica che descrive le transizioni di stato non è più racchiusa in istruzioni monolitiche Se O interruttore, ma distribuiti tra sottoclassi Stato. Incapsulando ogni transizione e azione in una classe, lo stato diventa un oggetto a tutti gli effetti. Ciò migliora la struttura del codice e ne rende più chiaro lo scopo. originale.ru
2. Rende esplicite le transizioni tra gli stati.
   Se un oggetto definisce il suo stato corrente esclusivamente in termini di dati interni, le transizioni tra stati non hanno una rappresentazione esplicita; appaiono solo come assegnazioni a determinate variabili. L'introduzione di oggetti separati per stati diversi rende le transizioni più esplicite. Inoltre, oggetti Stato può proteggere il contesto Contesto dalla mancata corrispondenza delle variabili interne, poiché le transizioni dal punto di vista del contesto sono azioni atomiche. Per effettuare la transizione è necessario modificare il valore di una sola variabile (variabile oggetto Stato in classe Contesto), piuttosto che diversi. source.ru
3. Gli oggetti di stato possono essere condivisi.
   Se in uno stato oggetto Stato non ci sono variabili di istanza, il che significa che lo stato che rappresenta è codificato esclusivamente dal tipo stesso, quindi contesti diversi possono condividere lo stesso oggetto Stato. Quando gli stati sono separati in questo modo, sono essenzialmente opportunisti (vedi modello opportunista) che non hanno uno stato interno, ma solo un comportamento. sito sorgente sito originale

Esempio

Prima di tutto definiamo la classe Connessione TCP, che fornisce un'interfaccia per il trasferimento dei dati e gestisce le richieste di modifica dello stato: TCPConnection. source.ru originale

In una variabile membro stato classe Connessione TCP viene memorizzata un'istanza della classe TCPState. Questa classe duplica l'interfaccia di modifica dello stato definita nella classe Connessione TCP. fonte originale.ru

sito sito di origine originale

Connessione TCP delega tutte le richieste dipendenti dallo stato all'istanza archiviata in state TCPState. Anche in classe Connessione TCP c'è un'operazione Cambia stato, con il quale puoi scrivere un puntatore a un altro oggetto in questa variabile TCPState. Costruttore di classi Connessione TCP inizializza stato puntatore allo stato chiuso TCPChiuso(lo definiremo di seguito). fonte originale.ru

source.ru originale

Ogni operazione TCPState accetta un'istanza Connessione TCP come parametro, consentendo così l'oggetto TCPState accedere ai dati dell'oggetto Connessione TCP e modificare lo stato della connessione. .ru

In classe TCPState ha implementato il comportamento predefinito per tutte le richieste ad esso delegate. Può anche cambiare lo stato di un oggetto Connessione TCP attraverso un'operazione Cambia stato. TCPState si trova nello stesso pacchetto di Connessione TCP, quindi ha accesso anche a questa operazione: TCPState . sito sito di origine originale

originale.ru

Nelle sottoclassi TCPState comportamento dipendente dallo stato implementato. Una connessione TCP può trovarsi in molti stati: Stabilito(installato), Ascoltando(ascoltando), Chiuso(chiuso), ecc., e ognuno di essi ha la propria sottoclasse TCPState. Per semplicità, considereremo in dettaglio solo 3 sottoclassi: TCPstabilito, TCPAscolta E TCPChiuso. fonte originale del sito web del sito web

Fonte Ru

Nelle sottoclassi TCPState implementa il comportamento dipendente dallo stato per le richieste valide in quello stato. .ru

sito sito di origine originale

Dopo aver eseguito azioni specifiche dello stato, queste operazioni fonte originale.ru

causa Cambia stato per modificare lo stato di un oggetto Connessione TCP. Lui stesso non ha informazioni sul protocollo TCP. Sono sottoclassi TCPState definire le transizioni tra stati e azioni dettate dal protocollo. originale.ru

fonte originale.ru

Applicazioni note del modello di stato

Per riflettere la dipendenza del comportamento dell'editor dallo strumento corrente, puoi utilizzare il modello di stato. fonte originale.ru

È possibile definire una classe astratta Attrezzo, le cui sottoclassi implementano il comportamento specifico dello strumento. L'editor grafico memorizza un collegamento all'oggetto corrente Purel e gli delega le richieste in arrivo. Quando selezioni uno strumento, l'editor utilizza un oggetto diverso, che fa sì che il comportamento cambi. .ru

Questa tecnica viene utilizzata nei framework degli editor grafici HotDraw e Unidraw. Consente ai clienti di definire facilmente nuovi tipi di strumenti. IN HotDraw Classe DrawingController inoltra le richieste all'oggetto corrente Attrezzo. IN Unidraw vengono chiamate le classi corrispondenti Spettatore E Attrezzo. Il diagramma delle classi riportato di seguito fornisce una rappresentazione schematica delle interfacce delle classi Attrezzo

Scopo del modello statale

• Il modello State consente a un oggetto di modificare il proprio comportamento a seconda del suo stato interno. Sembra che l'oggetto abbia cambiato classe.
• Il modello State è un'implementazione orientata agli oggetti di una macchina a stati.

Problema da risolvere

Il comportamento di un oggetto dipende dal suo stato e deve cambiare durante l'esecuzione del programma. Tale schema può essere implementato utilizzando molti operatori condizionali: in base all'analisi dello stato attuale dell'oggetto, vengono intraprese determinate azioni. Tuttavia, con un gran numero di stati, le istruzioni condizionali saranno sparse in tutto il codice e un programma del genere sarà difficile da mantenere.

Discussione sul modello statale

Il modello State risolve questo problema come segue:

• Introduce una classe Context che definisce un'interfaccia verso il mondo esterno.
• Introduce la classe astratta State.
• Rappresenta i vari "stati" di una macchina a stati come sottoclassi State.
• La classe Context ha un puntatore allo stato corrente che cambia quando cambia lo stato della macchina a stati.

Il modello di stato non definisce dove viene determinata esattamente la condizione per la transizione a un nuovo stato. Ci sono due opzioni: la classe Context o le sottoclassi State. Il vantaggio di quest'ultima opzione è che è facile aggiungere nuove classi derivate. Lo svantaggio è che ogni sottoclasse di stato deve conoscere i suoi vicini per effettuare una transizione verso un nuovo stato, il che introduce dipendenze tra le sottoclassi.

Esiste anche un approccio alternativo basato su tabelle per progettare macchine a stati finiti, basato sull'uso di una tabella che mappa in modo univoco i dati di input alle transizioni tra stati. Tuttavia, questo approccio presenta degli svantaggi: è difficile aggiungere l'esecuzione di azioni durante l'esecuzione delle transizioni. L'approccio del modello State utilizza il codice (invece delle strutture dati) per effettuare transizioni tra stati, quindi queste azioni sono facili da aggiungere.

Struttura del modello statale

La classe Context definisce l'interfaccia esterna per i client e memorizza un riferimento allo stato corrente dell'oggetto State. L'interfaccia della classe base astratta State è la stessa dell'interfaccia Context con l'eccezione di un parametro aggiuntivo: un puntatore a un'istanza Context. Le classi derivate dallo stato definiscono il comportamento specifico dello stato. La classe wrapper Context delega tutte le richieste ricevute a un oggetto "stato corrente", che può utilizzare il parametro aggiuntivo ricevuto per accedere all'istanza Context.

Il modello State consente a un oggetto di modificare il proprio comportamento a seconda del suo stato interno. Un'immagine simile può essere osservata nel funzionamento di un distributore automatico. Le macchine possono avere stati diversi a seconda della disponibilità delle merci, della quantità di monete ricevute, della capacità di scambiare denaro, ecc. Dopo che l'acquirente ha selezionato e pagato il prodotto, sono possibili le seguenti situazioni (stati):

• Consegnare la merce all'acquirente; non è necessario il resto.
• Dai la merce all'acquirente e cambiala.
• L'acquirente non riceverà la merce per mancanza di denaro sufficiente.
• L'acquirente non riceverà la merce a causa della sua assenza.

Utilizzando il modello di stato

• Definire una classe wrapper di contesto esistente o crearne una nuova da utilizzare dal client come "macchina a stati".
• Crea una classe State di base che replichi l'interfaccia della classe Context. Ogni metodo accetta un parametro aggiuntivo: un'istanza della classe Context. La classe State può definire qualsiasi comportamento "predefinito" utile.
• Crea classi derivate dallo stato per tutti gli stati possibili.
• La classe wrapper Context ha un riferimento all'oggetto dello stato corrente.
• La classe Context delega semplicemente tutte le richieste ricevute dal client all'oggetto “stato corrente”, con l'indirizzo dell'oggetto Context passato come parametro aggiuntivo.
• Utilizzando questo indirizzo, i metodi della classe State possono modificare, se necessario, lo "stato corrente" della classe Context.

Caratteristiche del modello statale

• Gli oggetti stato sono spesso singleton.
• Flyweight mostra come e quando gli oggetti Stato possono essere divisi.
• Il modello Interpreter può utilizzare State per definire i contesti di analisi.
• I modelli State e Bridge hanno strutture simili, tranne per il fatto che Bridge consente una gerarchia di classi di inviluppo (analoghi delle classi “wrapper”), mentre State no. Questi pattern hanno strutture simili, ma risolvono problemi diversi: State consente a un oggetto di cambiare il suo comportamento a seconda del suo stato interno, mentre Bridge separa l'astrazione dalla sua implementazione in modo che possano essere modificati indipendentemente l'uno dall'altro.
• L’attuazione del modello Stato si basa sul modello Strategia. Le differenze risiedono nel loro scopo.

Attuazione del modello statale

Consideriamo un esempio di macchina a stati finiti con due possibili stati e due eventi.

#includere utilizzando lo spazio dei nomi std; class Macchina ( class State *current; public: Machine(); void setCurrent(State *s) ( current = s; ) void on(); void off(); ); class State ( public: virtual void on(Machine *m) ( cout<< " already ON\n"; } virtual void off(Machine *m) { cout << " already OFF\n"; } }; void Machine::on() { current->su questo); ) void Macchina::off() ( corrente->off(questo); ) classe ON: public Stato ( public: ON() ( cout<< " ON-ctor "; }; ~ON() { cout << " dtor-ON\n"; }; void off(Machine *m); }; class OFF: public State { public: OFF() { cout << " OFF-ctor "; }; ~OFF() { cout << " dtor-OFF\n"; }; void on(Machine *m) { cout << " going from OFF to ON"; m->setCurrent(nuovo ON()); cancella questo; ) ); void ON::off(Macchina *m) ( cout<< " going from ON to OFF"; m->setCurrent(nuovo OFF()); cancella questo; ) Macchina::Macchina() ( corrente = nuovo OFF(); cout<< "\n"; } int main() { void(Machine:: *ptrs)() = { Machine::off, Machine::on }; Machine fsm; int num; while (1) { cout << "Enter 0/1: "; cin >>numero; (fsm. *ptrs)(); ) )

15.02.2016
21:30

Il modello State è destinato alla progettazione di classi con più stati logici indipendenti. Passiamo direttamente a un esempio.

Diciamo che stiamo sviluppando una classe di controllo della webcam. La fotocamera può trovarsi in tre stati:

1. Non inizializzato. Chiamiamolo NotConnectedState ;
2. Inizializzato e pronto all'uso, ma non è stato ancora acquisito alcun fotogramma. Lascia che sia ReadyState;
3. Modalità di acquisizione fotogrammi attivi. Indichiamo ActiveState .

Poiché stiamo lavorando con il modello di stato, è meglio iniziare con l'immagine del diagramma di stato:

Ora trasformiamo questo diagramma in codice. Per non complicare l'implementazione, omettiamo il codice per lavorare con le webcam. Se necessario, puoi aggiungere tu stesso le chiamate di funzione di libreria appropriate.

Fornirò immediatamente l'elenco completo con commenti minimi. Successivamente discuteremo i dettagli chiave di questa implementazione in modo più dettagliato.

#includere #define DECLARE_GET_INSTANCE(ClassName) \ static ClassName* getInstance() (\ static ClassName istanza;\ return \ ) class WebCamera ( public: typedef std::string Frame; public: // *********** *************************************** // Eccezioni // ****** ******************************************** classe NotSupported: pubblico std: :eccezione ( ); pubblico: // ***************************************** ******* ********* // Stati // ***************************** ******* ************** classe NotConnectedState; classe ReadyState; classe ActiveState; classe State ( public: virtual ~State() ( ) virtual void connect(WebCamera*) ( lanciare NotSupported(); ) virtual void Disconnect(WebCamera* cam) ( std::cout<< "Деинициализируем камеру..." << std::endl; // ... cam->changeState(NotConnectedState::getInstance()); ) virtual void start(WebCamera*) ( lancia NotSupported(); ) virtual void stop(WebCamera*) ( lancia NotSupported(); ) virtual Frame getFrame(WebCamera*) ( lancia NotSupported(); ) protetto: State() ( ) ); // ************************************************ ** classe NotConnectedState: public State ( public: DECLARE_GET_INSTANCE(NotConnectedState) void connect(WebCamera* cam) ( std::cout<< "Инициализируем камеру..." << std::endl; // ... cam->changeState(ReadyState::getInstance()); ) void disconnette(WebCamera*) ( lancia NotSupported(); ) privato: NotConnectedState() ( ) ); // ************************************************ ** class ReadyState: public State ( public: DECLARE_GET_INSTANCE(ReadyState) void start(WebCamera* cam) ( std::cout<< "Запускаем видео-поток..." << std::endl; // ... cam->changeState(ActiveState::getInstance()); ) privato: ReadyState() ( ) ); // ************************************************ ** classe ActiveState: public State ( public: DECLARE_GET_INSTANCE(ActiveState) void stop(WebCamera* cam) ( std::cout<< "Останавливаем видео-поток..." << std::endl; // ... cam-> << "Получаем текущий кадр..." << std::endl; // ... return "Current frame"; } private: ActiveState() { } }; public: explicit WebCamera(int camID) : m_camID(camID), m_state(NotConnectedState::getInstance()) { } ~WebCamera() { try { disconnect(); } catch(const NotSupported& e) { // Обрабатываем исключение } catch(...) { // Обрабатываем исключение } } void connect() { m_state->connetti(questo); ) void disconnessione() ( m_state->disconnect(questo); ) void start() ( m_state->start(questo); ) void stop() ( m_state->stop(questo); ) Frame getFrame() ( return m_state ->getFrame(this); ) privato: void changeState(State* newState) ( m_state = newState; ) privato: int m_camID; Stato* m_stato; );

Attiro la tua attenzione sulla macro DECLARE_GET_INSTANCE. Naturalmente l'uso delle macro in C++ è sconsigliato. Tuttavia, questo vale nei casi in cui la macro agisce come un analogo di una funzione modello. In questo caso, dare sempre la preferenza a quest'ultimo.

Nel nostro caso, la macro ha lo scopo di definire una funzione statica necessaria per implementare . Pertanto, il suo utilizzo può essere considerato giustificato. Dopotutto, consente di ridurre la duplicazione del codice e non rappresenta una minaccia seria.

Dichiariamo le classi State nella classe principale: WebCamera. Per brevità, ho utilizzato le definizioni in linea delle funzioni membro di tutte le classi. Tuttavia, nelle applicazioni reali è meglio seguire le raccomandazioni sulla separazione della dichiarazione e dell'implementazione nei file h e cpp.

Le classi di stato vengono dichiarate all'interno di WebCamera in modo che abbiano accesso ai campi privati ​​di quella classe. Naturalmente, questo crea una connessione estremamente stretta tra tutte queste classi. Ma gli Stati risultano così specifici che il loro riutilizzo in altri contesti è fuori discussione.

La base della gerarchia delle classi di stato è la classe astratta WebCamera::State:

Stato della classe ( public: virtual ~State() ( ) virtual void connect(WebCamera*) ( Throw NotSupported(); ) virtual void Disconnect(WebCamera* cam) ( std::cout<< "Деинициализируем камеру..." << std::endl; // ... cam->changeState(NotConnectedState::getInstance()); ) virtual void start(WebCamera*) ( lancia NotSupported(); ) virtual void stop(WebCamera*) ( lancia NotSupported(); ) virtual Frame getFrame(WebCamera*) ( lancia NotSupported(); ) protetto: State() ( ) );

Tutte le sue funzioni membro corrispondono alle funzioni della classe WebCamera stessa. La delega diretta avviene:

Classe WebCamera ( // ... void connect() ( m_state->connect(this); ) void disconnessione() ( m_state->disconnect(this); ) void start() ( m_state->start(this); ) void stop() ( m_state->stop(this); ) Frame getFrame() ( return m_state->getFrame(this); ) // ... State* m_state; )

La caratteristica fondamentale è che l'oggetto State accetta un puntatore all'istanza WebCamera che lo chiama. Ciò consente di avere solo tre oggetti State per un numero arbitrariamente elevato di telecamere. Questa possibilità è ottenuta attraverso l'uso del pattern Singleton. Naturalmente, nel contesto dell’esempio, non otterrai un guadagno significativo da questo. Ma conoscere questa tecnica è comunque utile.

Di per sé, la classe WebCamera non fa praticamente nulla. Dipende completamente dai suoi Stati. E questi Stati, a loro volta, determinano le condizioni per lo svolgimento delle operazioni e forniscono il contesto necessario.

La maggior parte delle funzioni membro di WebCamera::State generano la nostra WebCamera::NotSupported . Questo è un comportamento predefinito del tutto appropriato. Ad esempio, se qualcuno tenta di inizializzare una telecamera quando è già stata inizializzata, riceverà naturalmente un'eccezione.

Allo stesso tempo, forniamo un'implementazione predefinita per WebCamera::State::disconnect(). Questo comportamento è adatto a due dei tre stati. Di conseguenza, evitiamo la duplicazione del codice.

Per modificare lo stato, utilizzare la funzione membro privata WebCamera::changeState() :

Void changeState(State* newState) ( m_state = newState; )

Passiamo ora all'attuazione di Stati specifici. Per WebCamera::NotConnectedState è sufficiente sovrascrivere le operazioni connect() e disconnessione():

Classe NotConnectedState: public Stato ( public: DECLARE_GET_INSTANCE(NotConnectedState) void connect(WebCamera* cam) ( std::cout<< "Инициализируем камеру..." << std::endl; // ... cam->changeState(ReadyState::getInstance()); ) void disconnette(WebCamera*) ( lancia NotSupported(); ) privato: NotConnectedState() ( ) );

Per ogni Stato è possibile creare una singola istanza. Questo ci viene garantito dichiarando un costruttore privato.

Un altro elemento importante dell'implementazione presentata è che ci spostiamo in un nuovo Stato solo in caso di successo. Ad esempio, se si verifica un errore durante l'inizializzazione della fotocamera, è troppo presto per entrare in ReadyState. L'idea principale è la completa corrispondenza tra lo stato attuale della fotocamera (nel nostro caso) e l'oggetto State.

Quindi, la fotocamera è pronta per l'uso. Creiamo la classe WebCamera::ReadyState State corrispondente:

Classe ReadyState: public Stato ( public: DECLARE_GET_INSTANCE(ReadyState) void start(WebCamera* cam) ( std::cout<< "Запускаем видео-поток..." << std::endl; // ... cam->changeState(ActiveState::getInstance()); ) privato: ReadyState() ( ) );

Dallo stato Ready possiamo entrare nello stato attivo di Frame Capture. A questo scopo viene fornita l'operazione start(), che abbiamo implementato.

Finalmente abbiamo raggiunto l'ultimo stato logico della fotocamera, WebCamera::ActiveState:

Classe ActiveState: public State ( public: DECLARE_GET_INSTANCE(ActiveState) void stop(WebCamera* cam) ( std::cout<< "Останавливаем видео-поток..." << std::endl; // ... cam->changeState(ReadyState::getInstance()); ) Frame getFrame(WebCamera*) ( std::cout<< "Получаем текущий кадр..." << std::endl; // ... return "Current frame"; } private: ActiveState() { } };

In questo stato, puoi interrompere l'acquisizione di fotogrammi utilizzando stop() . Di conseguenza, verremo riportati alla WebCamera::ReadyState. Inoltre, possiamo ricevere fotogrammi che si accumulano nel buffer della fotocamera. Per semplicità, per “frame” intendiamo una stringa regolare. In realtà, questo sarà una sorta di array di byte.

Ora possiamo scrivere un tipico esempio di lavoro con la nostra classe WebCamera:

Int main() ( WebCamera cam(0); try ( // cam in NotConnectedState cam.connect(); // cam in ReadyState cam.start(); // cam in ActiveState std::cout<< cam.getFrame() << std::endl; cam.stop(); // Можно было сразу вызвать disconnect() // cam в Состоянии ReadyState cam.disconnect(); // cam в Состоянии NotConnectedState } catch(const WebCamera::NotSupported& e) { // Обрабатываем исключение } catch(...) { // Обрабатываем исключение } return 0; }

Questo è ciò che verrà visualizzato come risultato sulla console:

Inizializza la telecamera... Avvia il flusso video... Ottieni il fotogramma corrente... Fotogramma corrente Interrompi il flusso video... Deinizializza la telecamera...

Ora proviamo a provocare un errore. Chiamiamo connect() due volte di seguito:

Int main() ( WebCamera cam(0); try ( // cam nel NotConnectedState cam.connect(); // cam nel ReadyState // Ma per questo stato non è prevista l'operazione connect()! cam.connect( ); // Genera un'eccezione NotSupported ) catch(const WebCamera::NotSupported& e) ( std::cout<< "Произошло исключение!!!" << std::endl; // ... } catch(...) { // Обрабатываем исключение } return 0; }

Ecco cosa ne viene fuori:

Inizializzazione della fotocamera... Si è verificata un'eccezione!!! Deinizializziamo la fotocamera...

Tieni presente che la fotocamera era ancora deinizializzata. La chiamata disconnessione() si è verificata nel distruttore della WebCamera. Quelli. lo stato interno dell'oggetto rimane assolutamente corretto.

conclusioni

Utilizzando il modello State, puoi trasformare in modo univoco un diagramma di stato in codice. A prima vista, l'implementazione si è rivelata dettagliata. Tuttavia, siamo arrivati ​​​​a una chiara divisione in possibili contesti per lavorare con la classe principale WebCamera. Di conseguenza, durante la scrittura di ogni singolo Stato, abbiamo potuto concentrarci su un compito ristretto. E questo è il modo migliore per scrivere codice chiaro, comprensibile e affidabile.