Pattern#7 Event Driven

Nei precedenti articoli sui pattern, abbiamo utilizzato la struttura ad eventi, utilizzata negli stati Event/Idle per attendere un input da Interfaccia Grafica (UI).

In questo articolo vediamo il pattern Event Driven.

La programmazione Event Driven è caratterizzata dall’ordine di esecuzione del codice che viene guidato dall’utente.

Vediamo le tipologie di eventi:

Static Event

Eventi che a loro volta possono essere di tipo Notifier e o Filter (Prima di eseguire l’evento chiedo, es. PanelClose? permettono di annullare l’evento (Discard?=T).

Static Filter Event

Eventi Dinamici

Gli eventi dinamici, sono definiti da utente (User Event) mediante registrazione alla event structure.

Nell’articolo Queues Vs Notifier, abbiamo visto i Notifier (singolo elemento, no memoria, MultiWriter,MultiReader) e le Queues (Buffer, No perdita dati, MultiWriter SingleReader).

Il meccanismo degli user event è un mix tra i due, infatti può avere relazioni modificabili (Multi-Writer,Single-Reader e Multi-Writer,Multi-Reader) e funziona generando dati su un buffer FIFO, anche qui ogni buffer deve essere registrato quindi chi vuole ricevere i dati deve registrarsi all’evento.

Abbiamo quindi già un primo vantaggio rispetto alle code, inoltre l’evento lavora sul dato, per cui chi lo riceve riceve anche il dato.

Per spiegare meglio, facciamo riferimento alla QSM invio una stringa per decidere il case e un variant per passare il dato.

In questo caso invece l’evento è messaggio e porta con se il dato.

In questo caso è il parametro stesso a generare uno stato/evento, senza dover ricorrere al variant.

Queue Message
Event Message

Vantaggi principali dell’event driven.

  1. Mantengono memoria come per le code.
  2. MultiWriter e MultiReader.
  3. il messaggio incapsula il dato.
  4. Possono essere utilizzate in combinazione con eventi statici per le interfacce.

Use case Event Producer/Consumer

In questo esempio, abbiamo creato un evento (Create User Event), facendo attenzione di dare una label alla costante boolean (questo sarà il nome dell’evento nella struttura Event).

Ci sono tre processi con strutture ad eventi, nella prima che rappresenta il producer, non registriamo l’evento perchè sarà il generatore di eventi, ovvero lui non deve rispondere al <GlobalStop>:User Event, ma lo genera.

Gli altri due processi invece registrano lo User Event attraverso il metodo Register Event.

Infatti i due processi che saranno i consumer, aspettano l’evento e lo eseguono quando viene generato dal primo processo (UI-Handle).

Registrando questi eventi possiamo comunicare tra strutture ad eventi in cui quel particolare evento è stato registrato.

Conclusione

La programmazione Event Driven permette un utilizzo delle risorse più efficiente, semplifica il codice e permette il controllo di eventi dell’ interfaccia come eventi del mouse, finestre.