Command pattern

Da Wikipedia, l'enciclopedia libera.

Nella programmazione ad 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.

Indice 1 Struttura 2 Esempio 3 Considerazioni 4 Bibliografia

[modifica] Struttura

[modifica] Esempio

In un modulo è definito il seguente oggetto.

class RoomHandler:
    ...

Esso è destinato ad occuparsi della gestione delle camere di una casa e, attualmente, presiede anche allo svolgimento di alcuni lavori da eseguire.

Sono infatti definite, per ereditarietà, alcune sottoclassi che implementano lavori diversi da 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 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. 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).

Volendo quindi rifattorizzare il codice precedente:

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 """

Al momento della creazione di un RoomHandler è possibile selezionare i possibili lavori da 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())

[modifica] Considerazioni

1. Il ricevente dell'operazione (nel nostro caso una parete) non è deciso al momento della creazione dei lavori ma a tempo di esecuzione.
2. È possibile incapsulare un'azione in modo che essa sia atomica. In questo modo si implementa 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. Se necessario il Command, prima di eseguire, ricorda lo stato precedente alla sua esecuzione in modo da poter annullare la sua operazione.
4. È 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.

[modifica] Bibliografia

• Gamma, E., Helm, R., Johnson, R. e Vlissides, J., Design Patterns: elementi per il riuso di software a oggetti, Addison Wesley, 1995, ISBN 887192150X
  • Originale: Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995, ISBN 0201633612