Command pattern

Nella programmazione a oggetti, il Command pattern è uno dei pattern fondamentali, definiti originariamente dalla Gang of Four.

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

Struttura del Design Pattern Command

Esempio

In un modulo (python) è definita la classe che segue.

class RoomHandler:
    ...

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.

class Painter(RoomHandler)
    ...
    def actionWork(self, arguments):
        """ paint some walls """
        ...

class PaperGluer(RoomHandler)
    ...
    def actionWork(self, arguments):
        """ glue wallpaper to some walls """
        ...

class ShelfMounter(RoomHandler)
    ...
    def actionWork(self, arguments):
        """ mount shelves to some walls """

Questo approccio presenta diversi aspetti negativi.

1. 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.
2. 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.
3. 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:

class Command:

    def execute(self):
        raise NotImplementedError

class PaintWallCommand(Command)

    def execute(self, wall):
        """ paint a wall """

class GlueWallPaperCommand(Command)

    def execute(self, wall):
        """ glue wall paper to a wall """

class MountShelfCommand(Command)

    def execute(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:

def createRoomHandler(self):
    handler = RoomHandler()
    handler.addWork(PaintWallCommand())
    handler.addWork(MountShelfCommand())

class RoomHandler(self)
    ...
    def actionWork(self):
        for work in self.getWorks():
            work.execute(self.getSelectedWall())

Considerazioni

1. L'oggetto dell'operazione (nell'esempio la parete) non è deciso al momento della creazione delle azioni ma a tempo di esecuzione.
2. È 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.
3. 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.
4. È 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.

Bibliografia

• Gamma, E., Helm, R., Johnson, R. e Vlissides, J., Design Patterns: elementi per il riuso di software a oggetti, Addison Wesley, 1995, ISBN 88-7192-150-X.
  • Originale: Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995, ISBN 0-201-63361-2.

Altri progetti

Altri progetti

• Wikimedia Commons

• Wikimedia Commons contiene immagini o altri file su Command pattern