Questo approccio ha ha alcune conseguenze negative.
1.# 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.
2.# 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''.▼
3.# 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]].▼
▲2. 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''.
▲3. 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 90 ⟶ 88:
==Considerazioni==
1.# Il ricevente dell'operazione (nel nostro caso la parete dove lavorare) non è deciso al momento della creazione dei lavori da svolgere, ma a tempo di esecuzione.
2.# E'È possibile incapsulare un'azione in modo che essa sia atomica. In questo modo si implementerebbe un meccanismo di transazionalità in cui un'insieme di operazioni è svolto in toto o per nulla.▼
3.# I ''Command'', conoscendo le operazioni che devono svolgere, possono implementare anche un ''unexecute'' o ''undo''. Prima di eseguire, il Command, ricorda lo stato precedente alla sua esecuzione in modo da annullare eventualmente la sua operazione.▼
▲2. E' possibile incapsulare un'azione in modo che essa sia atomica. In questo modo si implementerebbe un meccanismo di transazionalità in cui un'insieme di operazioni è svolto in toto o per nulla.
4.# E'È 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.▼
▲3. I ''Command'', conoscendo le operazioni che devono svolgere, possono implementare anche un ''unexecute'' o ''undo''. Prima di eseguire, il Command, ricorda lo stato precedente alla sua esecuzione in modo da annullare eventualmente la sua operazione.
[[Categoria:Programmazione]]
▲4. E' 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.
