Command pattern: differenze tra le versioni

Versione delle 15:26, 25 giu 2005

Versione attuale delle 22:09, 4 gen 2025

(56 versioni intermedie di 41 utenti non mostrate)

Riga 1:

Nella [[Programmazione orientata agli oggetti|programmazione a oggetti]], il '''Command pattern''' è uno dei pattern fondamentali, definiti originariamente dalla [[Gang of Four (scrittori)|Gang of Four]].

Il '''Command''' è uno dei [[Design Patterns]]: si tratta di una soluzione standard ad un problema piuttosto comune nella progettazione del software.

Questo Pattern 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.

QuestoIl PatternCommand 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 importate è che il destinatario della richiesta può non essere deciso staticamente all'atto dell'istanziazione del command ma ricavato a run-time.

L'obiettivo è rendere variabile l'azione del client senza però conoscere i dettagli dell'operazione stessa. Altro aspetto importateimportante è che il destinatario della richiesta può non essere deciso staticamente all'atto dell'istanziazione del command ma ricavato a run-timetempo di esecuzione.

==Struttura==

== Struttura ==

[[Immagine:CommandPattern.png|center|Struttura del Design Pattern '''Command''']]

[[ImmagineFile:CommandPattern.png|center|Struttura del Design Pattern '''Command'''|bordo|549x549px]]

==Esempio==

== Esempio ==

In un modulo è definito il seguente oggetto.

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

<pre>

<syntaxhighlight lang=python>

class RoomHandler:

...

</syntaxhighlight>

</pre>

EssoQuesta è destinatodestinata ada occuparsi della gestione delle camere di una casa enonché, attualmente, presiede anche allo svolgimento di alcuni lavori da svolgereeseguire.

Sono infatti definiti, per ereditarietà,definite alcune sottoclassi che implementano diversi lavori diversiche è dapossibile eseguiresvolgere sulle pareti delle camere.

<syntaxhighlight lang=python>

<pre>

class Painter(RoomHandler)

...

Riga 38 ⟶ 39:

def actionWork(self, arguments):

""" mount shelves to some walls """

</syntaxhighlight>

</pre>

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.

Questo approccio presenta diversi aspetti negativi.

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''.

1.# SeA esistonofronte di ''n'' possibili lavori (azioni) ci si ritrovarendono costrettinecessarie ad avere moltediverse sottoclassi. Non solo: una per ciascuna azione da implementare mae anche quelle che servonouna per leogni possibilipossibile combinazionecomposizione di azioni che voglio ottenerebase (adper esempio dipingere camera e montarcimontare deglidi seguito gli scaffali). SeQualora invece le azioni sonofossero ''Command'' indipendenti dal RoomHandler, possosarebbe istanziarlipossibile creare istanze su quest'ultimo senzapiuttosto doverche subclassarecreare sottoclassi.

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 svolgeesegue ile lavoriazioni: inesso sostanzaè hasovraccarico troppedi responsabilità e se voglioed estendere un'azione lavorocomporta devoun complicareaumento didella conseguanzacomplessità anchedel ''RoomHandler''.

3.# Testare oggetti così complessi, con moltenumerose responsabilità, diventaè faticosoin egenere complesso e oneroso. SeIncapsulare le azioni sono incapsulate in ''Command'' testaterende separatamentepossibile riescoil atesting semplificareesclusivo anchesu iciascuna testazione (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:

Volendo quindi rifattorizzare il codice precedente:

<syntaxhighlight lang=python>

<pre>

class Command:

Riga 70 ⟶ 69:

def execute(self, wall):

""" mount shelf to a wall """

</syntaxhighlight>

</pre>

AlSia momentonell'atto delladi creazione di un'istanza ''RoomHandler'', sia a ''run-time'', è possibile selezionare ile azioni possibiliche lavorisi daintende svolgere:

<syntaxhighlight lang=python>

<pre>

def createRoomHandler(self):

handler = RoomHandler()

Riga 85 ⟶ 84:

for work in self.getWorks():

work.execute(self.getSelectedWall())

</syntaxhighlight>

</pre>

== Considerazioni ==

1.# Il riceventeL'oggetto dell'operazione (nel nostro casonell'esempio la parete dove lavorare) non è deciso al momento della creazione dei lavori dadelle svolgere,azioni ma a tempo di esecuzione.

==Considerazioni==

2.# E'È possibile incapsulare un'azione in modo che essaquesta sia atomica. InÈ questocosì modo sipossibile implementerebbeimplementare un meccanismoparadigma dibasato transazionalitàsu transazioni in cui un' insieme di operazioni è svolto in toto o per nulla.

3.# I ''Command'', conoscendoi lequali sono a conoscenza delle operazioni che devonosono chiamati a svolgere, possono implementare anchefunzioni undi ''unexecute'' o ''undo''. PrimaIn dicasi come eseguirequesti, il Command, ricordapuò memorizzare lo stato precedente alla sua esecuzione, inripristinandolo modoqualora dal'operazione annullaredebba eventualmenteessere la sua operazioneannullata.

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.

== Bibliografia ==

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.

* [[Erich Gamma|Gamma, E.]], [[Richard Helm|Helm, R.]], [[Ralph Johnson (informatico)|Johnson, R.]] e [[John Vlissides|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 ==

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.

{{interprogetto|preposizione=sul}}

{{Design pattern}}

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.

{{Portale|informatica}}

[[Categoria:Design pattern]]

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.