Modelli comportamentali, parte 2

2.1 Stato

Lo stato è un modello di progettazione comportamentale. Viene utilizzato in quei casi in cui, durante l'esecuzione del programma, l'oggetto deve cambiare il suo comportamento a seconda del suo stato.

Il modello è composto da 3 blocchi:

Il contesto è una classe i cui oggetti dovrebbero cambiare il loro comportamento a seconda dello stato.

Lo stato è l'interfaccia che ciascuno degli stati concreti deve implementare. Attraverso questa interfaccia, l'oggetto Context interagisce con lo stato delegando ad esso le chiamate al metodo. L'interfaccia dovrebbe contenere mezzi per il feedback all'oggetto il cui comportamento deve essere modificato.

Per questo, viene utilizzato un evento (pattern Publisher - Subscriber). Ciò è necessario per sostituire l'oggetto stato durante l'esecuzione del programma quando si verificano eventi. Ci possono essere casi in cui il contesto stesso interroga periodicamente l'oggetto stato per una transizione.

ConcreteState1, ConcreteState2 - classi di stati concreti. Dovrebbe contenere informazioni su in quali condizioni e in quali stati l'oggetto può passare dallo stato corrente. Ad esempio, da ConcreteState1, un oggetto può passare a ConcreteState2 e ConcreteState3, e da ConcreteState2 di nuovo a ConcreteState1 e così via. L'oggetto di uno di essi deve contenere il contesto al momento della creazione.

Ad esempio, stai scrivendo un gioco in cui un personaggio può correre, nuotare e volare. Se il tuo personaggio è entrato in acqua, è ragionevole limitare il suo comportamento in acqua: ora non può sparare, ma ha ancora alcune azioni: nuotare in avanti, a destra, a sinistra, ecc.

Lo stato del tuo personaggio può essere descritto da un oggetto State, che ha metodi che possono essere chiamati e che faranno qualcosa. E dopo che il tuo personaggio è entrato in acqua, devi solo cambiare il riferimento a un altro oggetto State al suo interno - e cambia il suo stato.

2.2 strategia

La strategia è un modello di progettazione comportamentale per definire una famiglia di algoritmi, incapsularli ciascuno e renderli intercambiabili. Ciò consente di scegliere un algoritmo definendo la classe appropriata.

Il modello di strategia consente di modificare l'algoritmo selezionato indipendentemente dagli oggetti client che lo utilizzano.

Il modello di strategia consente di utilizzare diverse regole o algoritmi di business a seconda del contesto. Viene utilizzato nei casi in cui è necessario utilizzare algoritmi diversi nello stesso luogo a seconda dello stato corrente del sistema (o del suo ambiente).

Punti di forza:

• incapsulamento dell'implementazione di vari algoritmi, il sistema diventa indipendente da possibili cambiamenti nelle regole aziendali;
• chiamare tutti gli algoritmi in un modo standard;
• non usare opzioni e/o istruzioni condizionali.

Questo modello è in qualche modo simile al modello Stato, ma qui l'enfasi non è sullo stato, ma sul comportamento. Diciamo che un personaggio nel tuo gioco può cambiare arma. Quindi, quando cambi arma, puoi semplicemente cambiare il riferimento all'oggetto che descrive come funziona quest'arma.

2.3 Metodo modello

Classe astratta (classe astratta) - definisce le operazioni astratte che vengono sostituite negli eredi per implementare i passaggi dell'algoritmo; implementa un metodo template che definisce lo scheletro dell'algoritmo. Il metodo del modello chiama le operazioni di sostituzione e di altro tipo definite nella classe Abstract.

Classe concreta (classe concreta): implementa le operazioni sostituite nel modo necessario per l'implementazione. La classe Concrete presuppone che i passaggi invarianti dell'algoritmo verranno eseguiti in AbstractClass.

Questo modello viene spesso utilizzato quando necessario:

• Singolo utilizzo della parte invariante dell'algoritmo, lasciando la parte variabile a discrezione degli eredi.
• Localizzazione e isolamento del codice comune a più classi per evitare duplicazioni.
• Consenti agli eredi di estendere il codice solo in determinati punti.

Sì, questo modello descrive l'uso di una coppia: una classe astratta e la sua implementazione.

2.4 Catena di responsabilità

La catena di responsabilità è un modello di progettazione comportamentale progettato per organizzare i livelli di responsabilità in un sistema.

Il modello è raccomandato per l'uso in condizioni in cui:

• nel sistema sviluppato è presente un gruppo di oggetti in grado di elaborare messaggi di un certo tipo;
• tutti i messaggi devono essere elaborati da almeno un oggetto di sistema;
• i messaggi nel sistema vengono elaborati secondo lo schema "elaboralo tu stesso o passalo ad un altro", ovvero alcuni messaggi vengono elaborati al livello in cui sono stati ricevuti, mentre altri vengono inoltrati a oggetti di un altro livello.

2.5 Ricordo

Keeper (Memento) è un modello di progettazione comportamentale che consente di correggere e salvare lo stato interno di un oggetto senza violare l'incapsulamento in modo che possa essere ripristinato a questo stato in un secondo momento.

Il modello Guardian viene utilizzato quando:

• è necessario salvare un'istantanea dello stato dell'oggetto (o parte di esso) per successivi restauri;
• L'interfaccia diretta per ottenere lo stato di un oggetto espone i dettagli dell'implementazione e interrompe l'incapsulamento dell'oggetto.