Intento:
Incapsulare una richiesta come se fosse un oggetto, quindi lasciare la possibilità di parametrizzare i vari Client in base alle richieste effettuate. In più aggiunge la possibilità di loggare o accodare richieste e supportare operazioni altrimenti non fattibili .
Applicabilità:
E’ utile sfruttare il Pattern Command nel caso n cui si voglia:
- parametrizzare gli oggetti per eseguire una determinata operazione
- specificare, accodare ed eseguire richieste in differenti periodi di tempo; difatti un oggetto di tipo Command può avere un tempo di vita indipendente rispetto alla richiesta originale
- sia supportata l’operazione di undo (operazione che rende possibile tornare allo stato precedete dell’operazione in questione)
- ci sia il supporto per effettuare cambiamenti nel processo di logging in modo tale che sia possibile riabilitare il sistema in caso di crash.
- Strutturare un sistema attorno a operazioni ad alto livello costruite però su operazioni primitive, in parole povere un sistema che supporti le transazioni.
Partecipanti:
- Command → dichiara una interfaccia per eseguire una operazione
- ConcreteCommand → definisce un legame fra l’oggetto Receiver e l’azione; implementa l’operazione Execute invocando la corrispondente operazione/i presenti nel Receiver
- Client → crea un oggetto ConcreteCommand e imposta il Receiver
- Invoker → richiede il comando per convogliare la richiesta
- Receiver → conosce come gestire le operazioni associate al trasporto della richiesta. Ogni classe può essere n Receiver
Conseguenze:
- In primis il pattern disaccoppia gli oggetti che invocano l’operazione da quelli che conoscono come eseguirla
- I Commands sono veri e propri oggetti e come tali possono essere estesi e manipolati
- Si possono assemblare più commad creando un composite command
- E’ facile aggiungere nuovi Command dato che non è necessario variare alcuna classe esistente.
[...] Command [...]