Command pattern: differenze tra le versioni

Versione delle 22:36, 8 mar 2022

Versione delle 22:37, 8 mar 2022

Riga 43:

Questo approccio presenta diversi aspetti negativi.

# A fronte di ''n'' possibili lavori (azioni) si rendono necessarie diverse sottoclassi: una per ciascuna azione da implementare ede una per ogni possibile composizione di azioni base (adper 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 ede oneroso. Incapsulare le azioni in ''Command'' rende possibile il testing esclusivo su ciascuna azione (eventualmente ricorrendo all'uso di [[Mock Objects|Mock]]) il che semplifica notevolmente la fase di testing e validazione.

Segue il codice equivalente strutturato seguendo le indicazioni del pattern: