Recentemente mi sono imbattuto per motivi universitari in questo pattern. La sua funzione quale è? cito dal wiki di UgiDotNet [che si ispira da DoFactory]:

Il design pattern Command permette (alla classe Client) di incapsulate una richiesta, ossia un comando (Execute) da eseguire ed i suoi parametri (state), sotto forma di oggetto (ConcreteCommand) da usare per parametrizzare il comportamento di altri oggetti (Invoker) con diverse richieste (ossia con diversi oggetti ConcreteCommand), code di richieste oppure log di richieste.

Con la figura forse risulta più chiaro

Command Pattern
Se ancora non lo fosse provo a spiegarlo a parole mie "ha lo scopo di inglobare/nascondere la sintassi (magari complessa) di un comando dietro una classe e permettere di trasferire l'oggetto tra varie parti del programma per venir eseguito magari altrove (anche fisicamente)". I più attenti noteranno che le due frasi non coincidono, infatti secondo me la frase del wiki non è corretta anzi contiene pure una errata valutazione di state! Se uso questo pattern, siamo tutti daccordo, è per nascondere/incapsulare una comlessità agli occhi di un client; ora questo comporta il beneficio di poter eseguire una serie di comandi dietro l'invocazione di un metodo generico quale Execute(). Mi spiego meglio se chiedo ad esempio addMoney(300) su una classe Conto mi aspetto che aggiunga 300 al mio conto, se eseguo Money.Execute(); potrei voler eseguire non solo add ma anche remove in una qualunque sequenza. Es:
$money = new Money('banca','username','password');

$money->add(300);

$money->add(100);

$money->remove(50) ;

$money->Execute();

echo $money->State();

Ora i più attenti mi diranno : “Ehi ma allora anche add e remove devono andare nella interfaccia comune di Command”? No,ovviamente. Mentre State come vedete alla fine lo uso per sapere lo stato dell’operazione tipo: training, attending, failed,suspended. Tutto questo è possibile presupponendo che chi usa la classe Money conosca i metodi in aggiunta a quelli dell’interfaccia di Command. Questa non sembra una soluzione acettabile allora posso usare la stessa tecnica usata in SQL dai vari driver in circolazione:

$money = new Money('banca','username','password');

$money->prepare('add','300');

$money->prepare('add','100');

$money->prepare('remove','50');

$money->Execute();

echo $money->State();

L’introduzione di prepare permette di avere un miglior controllo della situazione, semplificando la creazione di Money (meno funzioni da implementare). A questo punto basta sbizarrirsi un pò per vedere i vantaggi di questo pattern: legato al proxy permette di eseguire comandi su macchine remote o utilizzare servizi remoti. Notare quindi come nel grafico UML non venga specificato come il Receiver debba essere implementato ma fornisca uno schema logico ad ampio spettro. Per la cronaca la mia soluzione è quella che si avvicina di più al GOF usando interfacce e non classi astratte.

PS: una interessante immagine con le relazioni tra patterns.