Dal QMH al ObjectCommandPattern

Dal Cluster alla Classe.

Il QMH è stato per molto tempo il mio pattern preferito in quanto molto flessibile e supportato in RT e WIN.

Passando alle classi il pattern che piu gli si accosta è il “Command Pattern”.

Per citare Wikipedia:

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.

In pratica si tratta di

  1. Incapsulare tutti i comandi in classi figlie della classe command
  2. Inviare i messaggi non piu come cluster ma utilizzando un metodo statico della classe del comando da eseguire.

La stessa applicazione fatta con QMH (poteva ancora essere migliorata) e ObjectCmdPattern.

 

 

 

 

 

 

 

 

 

Utilizzando un design command pattern, con tanta pazienza e tempo (anche se utilizzando il toolkit NI GOOP, viene facilitato di molto il compito), si confeziona ogni comando in una classe.

QMH Le differenze

 

In un processo QMH, ogni azione deve essere inserita nell’applicazione , aggiungendo uno stato al Case.

 

 

Nel ObjectCmndPattern, solo il DO.vi della classe parent viene inserito nel processo.

Cosi posso ora aggiungere il codice di esecuzione dei comandi, creando una classe con un metodo DO come override del DO del parent (attenzione ricorda che deve avere gli stessi terminali e lo stesso nome del DO del Parent Class).

Per me un altro vantaggio è anche il fatto di poter verificare la lista dei comandi e il probe della classe mi mostra tutte le info sulla classe (che poi in definitiva è un cluster type def protetto).

Ma come chiedo di fare le azioni DO che ho collezionato nel processo?

Per ogni classe creare un metodo send statico che viene utilizzato per inviare (io utilizzo le code ma potete utilizzare altri modelli di comunicazione) i comandi semplicemente inviando la classe del comando, ovviamente per ogni classe è possibile modificare i dati in modo che nell’invio si può anche inviare i dati.

Metodo Send per eseguire il comando.

QMH(Msg)=(OOP)Class Method DO

QMH(Variant)=(OOP)Class Data

 

 

 Devo ammettere che passare dal QMH o DQMH a un patern basato sulle classi non è stato un passo semplice, ci sono tanti punti in cui ci si potrebbe chiedere perchè devo fare questa fatica a crear classi etc. quando con il QMH posso farlo piu rapidamente.

Proprio perchè è piu astratto e separato dal resto del codice, quindi si può passare dalla specifica UML al codice. E una volta fatta un po di pratica diventa persino piu rapido, sfruttando anche i tool come GOOP che tra l’altro possiedono un editor UML che ha la possibilità di generare il codice sul progetto direttamente dall’editor.

%d blogger hanno fatto clic su Mi Piace per questo: