Command pattern: differenze tra le versioni

Versione delle 20:39, 25 giu 2005

Versione delle 14:05, 27 giu 2005

Riga 1:

{{wikificare}}

Il '''Command pattern''' è uno dei [[Designdesign Patternspattern]]: si tratta di una soluzione standard ad un problema piuttosto comune nella progettazione del software.

Questo Pattern permette di isolare la porzione di codice che effettua un'azione (eventualmente molto complessa) dal codice che ne richiede l'esecuzione; l'azione è incapsulata nell'oggetto Command.

L'obiettivo è rendere variabile l'azione del client senza però conoscere i dettagli dell'operazione stessa. Altro aspetto importate è che il destinatario della richiesta può non essere deciso staticamente all'atto dell'istanziazione del command ma ricavato a run-timetempo di esecuzione.

==Struttura==

Riga 18:

</pre>

Esso è destinato ad occuparsi della gestione delle camere di una casa e, attualmente, presiede anche allo svolgimento di alcuni lavori da svolgereeseguire.

Sono infatti definitidefinite, per ereditarietà, alcune sottoclassi che implementano lavori diversi da eseguiresvolgere sulle pareti delle camere.

<pre>

Riga 44:

# Se esistono ''n'' possibili lavori (azioni) ci si ritrova costretti ad avere molte sottoclassi. Non solo una per azione da implementare ma anche quelle che servono per le possibili combinazione di azioni che voglio ottenere (ad esempio dipingere camera e montarci degli scaffali). Se invece le azioni sono ''Command'' indipendenti dal RoomHandler, posso istanziarli su quest'ultimo senza dover subclassare.

# Se ''RoomHandler'' contiene sia il codice di gestione delle camere che il codice che svolge i lavori: in sostanza ha troppe responsabilità e se voglio estendere un lavoro devo complicare di conseguanza anche ''RoomHandler''.

# Testare oggetti così complessi, con molte responsabilità, diventa faticoso e complesso. Se le azioni sono incapsulate in ''Command'' testate separatamente riesco a semplificare anche i test (eventualmente ricorrendo all'uso di [[Mock Objects|Mock]]).

Volendo quindi rifattorizzare il codice precedente:

Riga 89:

==Considerazioni==

# Il ricevente dell'operazione (nel nostro caso launa parete dove lavorare) non è deciso al momento della creazione dei lavori da svolgere, ma a tempo di esecuzione.

# È possibile incapsulare un'azione in modo che essa sia atomica. In questo modo si implementerebbeimplementa un meccanismo di transazionalità in cui un'insieme di operazioni è svolto in toto o per nulla.

# I ''Command'', conoscendo le operazioni che devono svolgere, possono implementare anche un ''unexecute'' o ''undo''. PrimaSe di eseguire,necessario il Command, prima di eseguire, ricorda lo stato precedente alla sua esecuzione in modo da annullarepoter eventualmenteannullare la sua operazione.

# È possibile rendere asincrona la scelta dei comandi rispetto alla loro esecuzione. Un certo numero di command, selezionati da un client, possono essere ''consumati'' da un'altro oggetto che li riceve in un tempo diverso dalla loro selezione.