Memento

Intento:

Senza violare l’incapsulamento, cattura lo stato interno di un oggetto e lo “esterna” così che l’oggetto può essere ripristinato al suo stato precedente.

Applicabilità:

Memento è da utilizzare nel caso in cui:

• uno snapshot (istantanea) di un oggetto o di una parte di esso deve essere salvata al fine di poter ripristinare il suo stato in un momento successivo
• una interfaccia diretta al fine di ottenere lo stato dell’oggetto potrebbe esporre il dettaglio implementativo dell’oggetto stesso e rompere l’incapsulamento.

Partecipanti:

• Memento → Mantiene lo stato interno dell’oggetto Originator, inoltre protegge lo stesso oggetto da altri oggetti
• Originator → crea l’oggetto Memento che contiene l’istantanea dello stato corrente di Originator, utilizza Memento per ripristinare un suo stato precedente
• Caretaker → è responsabile della custodia di Memento, ma non ne gestisce o esamina il contenuto

Conseguenze:

• Vengono preservati i limiti dell’incapsulamento, infatti Memento espone quelle informazioni che solo un oggetto Originator potrebbe gestire, ma che non potranno mai essere immagazzinate all’esterno dell’originator stesso
• Originator stesso viene semplificato.
• Sfruttare questo pattern può essere dispendioso in termini di risorse
• Ci sono dei costi nascosti nella gestione dello stato degli oggetti

Command

Intento:

Incapsulare una richiesta come se fosse un oggetto, quindi lasciare la possibilità di parametrizzare i vari Client in base alle richieste effettuate. In più aggiunge la possibilità di loggare o accodare richieste e supportare operazioni altrimenti non fattibili .

Applicabilità:

E’ utile sfruttare il Pattern Command nel caso n cui si voglia:

• parametrizzare gli oggetti per eseguire una determinata operazione
• specificare, accodare ed eseguire richieste in differenti periodi di tempo; difatti un oggetto di tipo Command può avere un tempo di vita indipendente rispetto alla richiesta originale
• sia supportata l’operazione di undo (operazione che rende possibile tornare allo stato precedete dell’operazione in questione)
• ci sia il supporto per effettuare cambiamenti nel processo di logging in modo tale che sia possibile riabilitare il sistema in caso di crash.
• Strutturare un sistema attorno a operazioni ad alto livello costruite però su operazioni primitive, in parole povere un sistema che supporti le transazioni.

Partecipanti:

• Command → dichiara una interfaccia per eseguire una operazione
• ConcreteCommand → definisce un legame fra l’oggetto Receiver e l’azione; implementa l’operazione Execute invocando la corrispondente operazione/i presenti nel Receiver
• Client → crea un oggetto ConcreteCommand e imposta il Receiver
• Invoker → richiede il comando per convogliare la richiesta
• Receiver → conosce come gestire le operazioni associate al trasporto della richiesta. Ogni classe può essere n Receiver

Conseguenze:

• In primis il pattern disaccoppia gli oggetti che invocano l’operazione da quelli che conoscono come eseguirla
• I Commands sono veri e propri oggetti e come tali possono essere estesi e manipolati
• Si possono assemblare più commad creando un composite command
• E’ facile aggiungere nuovi Command dato che non è necessario variare alcuna classe esistente.