La gestione degli eventi.

L'uso di interfacce grafiche ha introdotto un grosso cambiamento nella programmazione. Prima dell'avvento della grafica, i programmi interattivi erano organizzati a menu, e l'utente era costretto a seguire una interazione dall'inizio alla fine. L'uso di finestre, mouse e pulsanti ha introdotto invece un modello di programmazione event driven, in cui il programma principale resta in uno stato di attesa fino a quando l'utente genera un evento che provoca un determinato effetto.

Il modello ad eventi

In Java ogni oggetto grafico è predisposto a ricevere un certo numero di eventi dall'utente: un pulsante può essere premuto, una finestra può essere chiusa, il mouse può essere spostato e così via.

La gestione di questi eventi segue un modello definito in letteratura Event Delegation, in cui il componente grafico delega ad un ascoltatore l'azione da svolgere.

Un pulsante non sa cosa avverrà alla sua pressione: esso si limita a notificare i propri ascoltatori che l'evento che essi attendevano è avvenuto, e questi provvederanno ad eseguire l'azione appropriata.

Ogni componente grafico può avere più di un ascoltatore per un determinato evento; in questo caso essi saranno chiamati uno per volta secondo l'ordine in cui si sono registrati. Se l'utente cerca di scatenare un nuovo evento prima che il precedente sia stato consumato, ad esempio premendo ripetutamente un pulsante, ogni nuovo evento verrà bufferizzato e l'azione corrispondente sarà eseguita solo al termine della precedente.

Il Pattern Observer-Observable

Il modello event driven è una implementazione del pattern Observer-Observable.

Si ha un oggetto in grado di scatenare un determinato tipo di evento, chiamato Observable, che mantiene una lista di ascoltatori definiti dall'interfaccia Observer all'interno di un vettore listeners.

Un ascoltatore può registrarsi presso Observable usando il metodo addListener(), mentre si esclude dalla lista degli ascoltatori chiamando removeListener().

Ogni volta che capita un evento, Observable chiama il metodo protetto processEvent(), che esegue il metodo actionPerformed() su tutti gli ascoltatori presenti nel vettore listeners; la notifica prevede lo scambio di oggetti Event, che sono in grado di fornire dettagli sull'evento generato.

L'ascoltatore viene definito come una interfaccia Java; questa scelta pone al programmatore un vincolo riguardo a come scrivere un ascoltatore, ma lascia completa libertà su cosa l'ascoltatore debba fare.

Un esempio concreto

Ogni Component è in grado di notificare gli eventi generati dal mouse; in particolare è predisposto per lavorare con due tipi di ascoltatori:

• MouseListener
• MouseMotionListener

Il primo è interessato principalmente alla pressione dei pulsanti del mouse, il secondo allo spostamento del puntatore. La relazione tra questi oggetti ricalca fedelmente il pattern Observer-Observable.

L'articolo propone poi la costruzione di un semplice programma di disegno usando tre classi, a partire da una classe Painter, sottoclasse di JPanel, che costituisce la classe principale del programma.

Conclusioni

Questa terza parte del corso mostra che il vero cuore di una GUI Swing non è soltanto nei componenti, ma nel modo in cui essi reagiscono agli eventi.

Capire event delegation, il pattern Observer-Observable e la gestione di MouseListener e MouseMotionListener significa comprendere la meccanica interna con cui un'interfaccia Java diventa interattiva.