Il Command pattern è uno dei design pattern che 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 importante è che il destinatario della richiesta può non essere deciso staticamente all'atto dell'istanziazione del command ma ricavato a tempo di esecuzione.
Struttura
Esempio
In un modulo (python) è definita la classe che segue.
classRoomHandler:...
Questa è destinata a occuparsi della gestione delle camere di una casa nonché, attualmente, allo svolgimento di alcuni lavori da eseguire.
Sono infatti definite alcune sottoclassi che implementano diversi lavori che è possibile svolgere sulle pareti delle camere.
classPainter(RoomHandler)...defactionWork(self,arguments):""" paint some walls """...classPaperGluer(RoomHandler)...defactionWork(self,arguments):""" glue wallpaper to some walls """...classShelfMounter(RoomHandler)...defactionWork(self,arguments):""" mount shelves to some walls """
Questo approccio presenta diversi aspetti negativi.
A fronte di n possibili lavori (azioni) si rendono necessarie diverse sottoclassi: una per ciascuna azione da implementare e una per ogni possibile composizione di azioni base (per esempio dipingere camera e montare di seguito gli scaffali). Qualora invece le azioni fossero Command indipendenti dal RoomHandler, sarebbe possibile creare istanze su quest'ultimo piuttosto che creare sottoclassi.
RoomHandler contiene sia il codice di gestione delle camere che il codice che esegue le azioni: esso è sovraccarico di responsabilità ed estendere un'azione comporta un aumento della complessità del RoomHandler.
Testare oggetti con numerose responsabilità è in genere complesso e oneroso. Incapsulare le azioni in Command rende possibile il testing esclusivo su ciascuna azione (eventualmente ricorrendo all'uso di Mock) il che semplifica notevolmente la fase di testing e validazione.
Segue il codice equivalente strutturato seguendo le indicazioni del pattern:
classCommand:defexecute(self):raiseNotImplementedErrorclassPaintWallCommand(Command)defexecute(self,wall):""" paint a wall """classGlueWallPaperCommand(Command)defexecute(self,wall):""" glue wall paper to a wall """classMountShelfCommand(Command)defexecute(self,wall):""" mount shelf to a wall """
Sia nell'atto di creazione di un'istanza RoomHandler, sia a run-time, è possibile selezionare le azioni che si intende svolgere:
L'oggetto dell'operazione (nell'esempio la parete) non è deciso al momento della creazione delle azioni ma a tempo di esecuzione.
È possibile incapsulare un'azione in modo che questa sia atomica. È così possibile implementare un paradigma basato su transazioni in cui un insieme di operazioni è svolto in toto o per nulla.
I Command, i quali sono a conoscenza delle operazioni che sono chiamati a svolgere, possono implementare funzioni di unexecute o undo. In casi come questi, il Command può memorizzare lo stato precedente alla sua esecuzione, ripristinandolo qualora l'operazione debba essere annullata.
È possibile rendere asincrona la scelta dei comandi rispetto alla loro esecuzione. Un certo numero di command possono essere consumati da un altro oggetto che li riceve in un tempo diverso dalla loro selezione.