La progettazione di un software è sempre una parte molto delicata e spesso giunti alla GUI sorge un problema: come la si separa dal resto del codice?
In questo articolo darò alcune linee guida generiche, e poi mostrerò 3 esempi veri e propri, utilizzando il gioco del Tris. Mi preme sottolineare che gli esempi sono molto limitati e che non coprono sicuramente tutti i possibili scenari.
L'implementazione di Tris sarà nella versione più semplice possibile: Human vs. Human.

• Introduzione e Panoramica


• Approccio errato: mischiare logica e GUI


• Panoramica sulla composizione di una GUI


• Separare i dati dal codice
  
  
  • Esempio
  
  


• L'approccio MVC
  
  
  • Esempio
  
  


• L'approccio MVC con evento personalizzato
  
  
  • Esempio
  
  

---

Intruduzione e Panoramica

L'articolo affronterà i punti così come da indice. Il primo caso non verrà analizzato tramite codice, trattandosi dell'approccio errato.
Il secondo caso mostra invece l'approccio più semplice per separare i dati su cui opera il software dalla grafica dell'applicazione.
Il terzo invece presenta uno degli approcci più interessanti ed ordinati: MVC. Si tratta del classico Model View Controller dove il Model manipola i dati su cui il software opera (e ne implementa la logica); il Controller fa da tramite tra la logica e la grafica, gestendo gli eventi della GUI; ed il View mostra l'elaborazione dei dati e permette di interagire (provocando eventi).

Approccio Errato: mischiare dati e logica con la GUI

Questo tipo di approccio è tipicamente utilizzato - inizialmente, si spera - da chi non ha competenze di progettazione e non conosce probabilmente bene nemmeno le GUI. Consiste nel creare un'interfaccia grafica che gestisce anche la logica. Un classico esempio potrebbe essere l'estensione di una finestra grafica di Swing (JFrame), l'implementazione di uno o più listeners per gestire gli eventi, e la creazione dei dati su cui si deve operare, come ad esempio un elenco di persone memorizzato in un array e metodi incaricati magari all'inserimento ed all'eliminazione.

Ora è lecito chiedersi: cosa rende così errato questo approccio?
Un'implementazione come questa ha differenti ripercussioni, sia da un punto di vista della manutenibilità della GUI, sia da quello della logica. La GUI ne risentirà in quanto un minimo cambio al suo aspetto grafico provocherà la riscrittura - o il riadattamento - di parti di codice che accede ai dati, non avendo separazioni. Di fatto quindi non si potrà modificare solo la GUI, ma si è costretti a toccare anche i dati su cui si opera.
Un cambio della logica dell'applicativo si rifletterà invece sulla GUI, in quanto non si ha alcun livello di astrazione tra i due.

L'importanza dell'Astrazione
La programmazione così come tanti altri aspetti del nostro quotidiano si basano su qualche forma di astrazione. L'astrazione consiste nell'incapsulare la complessità di qualcosa, così da renderne semplice l'utilizzo. Un classico esempio è l'automobile: è necessario sapere cosa accade dettagliatamente quando si preme l'acceleratore, o la frizione? Fondamentalmente no, non è necessario. Tutto ciò che facciamo è premere l'acceleratore per incrementare la velocità, non ci serve sapere cosa accade esattamente.

Nell'ambiente informatico questo aspetto torna molto. Si pensi ad esempio alla gestione dell'I/O da un dispositivo, sia esso una tastiera. Quando leggiamo un input dal così definito "flusso di input predefinito" (la tastiera, stdin), tutto ciò che facciamo è utilizzare una funzione o una classe - nel caso della OOP - che incapsula la complessità su più strati.
Il discorso è analogo all'allocazione della memoria. In Java si alloca memoria per un oggetto utilizzando l'operatore new. In C esistono funzioni per allocare dinamicamente la memoria, come malloc(). Questa funzione a sua volta si appoggia - sotto Windows - alla libreria di Windows per gestire l'allocazione (invocando HeapAlloc).

Tutto ciò cosa ci permette di comprendere? Che quando creiamo una o più classi per gestire la logica del nostro programma, forniremo dei metodi di accesso a tali dati, e sarà sufficiente richiamare questi metodi per astrarre tutta la complessità di una data operazione.

Panoramica sui componenti grafici utilizzati nelle applicazioni

La libreria di Java mette a disposizioni due librerie per la gestione delle GUI. Una è l'Abstract Window Toolkit, conosciuto come AWT, che fornisce gli strumenti necessari al rendeering grafico, alla gestione di finestre, bottoni, pannelli, campi di testo, etichette, menu a tendina, ed eventi su essi. Questa libreria attualmente - e da un pò di anni a questa parte in realtà - non viene più utilizzata direttamente. La libreria inizialmente era poco più di un'astrazione della libreria reale del sistema operativo; la si considera una libreria ad un più basso livello rispetto alla seconda, Swing.

Swing è stata introdotta a partire da Java 1.2 ed è scritta in Java, utilizzando librerie di Java (come Java 2D). Tuttavia essendo ad un livello più alto, si va ad appoggiare su AWT. Se guardiamo ad esempio il componente JFrame, ci accorgeremo che estende java.awt.Frame.

Tutto ciò che serve per creare una GUI lo si trova tipicamente in 2 package: java.awt.*; e javax.swing.* e per la gestione degli eventi java.awt.event.*. Per capire se quello che stiamo vedendo nel codice è un oggetto appartenente ad AWT o a Swing è sufficiente guardare il suo prefisso; tutti i componenti Swing iniziano infatti con una J. Alcuni esempi sono: JFrame, JPanel, JComboBox, JTextField, etc. Tutte le versioni senza J appartengono ad AWT.

Per una trattazione completa sul funzionamento di tutte le parti coinvolte vi invito a leggere sul sito di Oracle il tutorial Using Swing Components.

Chiariti questi aspetti, mostrerò di seguito una rapidissima panoramica sui componenti principali e su come si utilizzano.
JFrame: si tratta della finestra principale di un'applicazione, o di una finestra secondaria di un applicazione. Ogni qualvolta si necessita di una finestra, può essere istanziato un nuovo oggetto JFrame. Ci sono più approcci per la creazione della finestra: si può estendere JFrame, o si può creare un oggetto JFrame.

JPanel: è il pannello che racchiude i componenti della finestra, come campi di testo, etichette di testo, menu a tendina, bottoni etc. Tutto di solito lo si racchiude in un JPanel, che a sua volta, verrà aggiunto ad un JFrame. Un JPanel dispone i componenti sulla base del LyoutManager che sta utilizzando. Quando si crea un'istanza di JPanel senza passare nulla al costruttore, internamente JPanel utilizzerà un layout chiamato FlowLayout. La regola di questo layout è che tutti i componenti verranno aggiunti sulla riga: quando non ci sarà più spazio, continueranno sulla riga sottostante.

I Layout sono molti, ed inoltre è possibile creare un proprio Layout (non che ve ne sia sempre bisogno, anzi). Giusto per citarne alcuni: FlowLayout, BorderLayout, GridLayout, GridBagLayout.

JPanel è molto utilizzato, come si può intuire. Permette di incapsulare gli eleemnti della GUI, ma anche di disegnare su essa. E' infatti possibile effettuare un override del metodo public void paintComponent(Graphics); per disegnare su un pannello. Solitamente quando si ha questo tipo di necessità si crea un proprio pannello. Creare un proprio pannello è come creare una propria finestra: è sufficiente estendere il componente, tipo class MyPanel extends JPanel { ... }.

JLabel: come dice il nome stesso si tratta della classica etichetta di testo che solitamente è affiancata ad un componente come un'area di testo o un menu a tendina. E' anche possibile disegnare su un JLabel, come si fa per JPanel.

Questi sono più o meno i componenti che verranno utilizzati. Non trattandosi di un articolo dedicato alla creazione di GUI ma alla loro progettazione, non tratterò in maniera approfondita null'altro.

Primo Approccio: separare la logica dall'interfaccia grafica

Il primo approccio che presenterò è largamente utilizzato da chi - di solito - scrive in maniera corretta un'applicazione grafica. Ciò che presenterò non dovrà essere però preso alla lettera in quanto vi possono essere sfaccettature: io utilizzerò ciò che si vede più comunemente, l'estensione di JFrame. Tuttavia, un'implementazione analoga la si può avere creando un oggetto JFrame nella classe che gestisce la GUI.

L'esempio che vedrete sarà composto da 3 sole classi. Ci sarà una classe chiamata TrisModel che gestirà la logica dell'applicativo; una classe chiamata TrisView che gestirà grafica ed eventi con tanto di main(); ed una classe GridCell che gestirà il disegno su una JLabel (GridCell estende JLabel).

E' importante sottolineare che si potranno creare il numero di classi più opportune per gestire Model e View. Non è necessario - ed anzi non dovrebbe - stare tutto il model in un'unica classe (il discorso è sempre quello dell'astrazione, ed anche dell'incapsulamento). Ho utilizzato questi nomi di classi solo ed unicamente per far intendere la differenza tra la logica e la GUI, ma non sono necessariamente correlate ad un implementazione MVC.

Analisi di TrisModel.java

Le variabili presenti sono:



Le prime costanti verranno utilizzate all'esterno della classe, per capire in quale stato si trova attualmente il model (ed aggiornare la GUI). Le altre sono nel perfetto stile di una classe Java: privati e definiti come costanti, quando serve.
Il campo di gioco l'ho gestito con un'array al posto di utilizzare una matrice.

Il costruttore inizializza il campo:


Le variabili next e old memorizzano il prossimo giocatore ed il precedente, rispettivamente.
Come si sarà capito il cuore della logica del gioco è sicuramente il campo di gioco, o per meglio dire, gli stati del campo di gioco. Ecco quindi in che modo avviene una mossa:



checkIfValid() verifica se la posizione clickata e rappresentata da (x,y) è vuota (valida) oppure è già occupata, restituendo true/false.
L'altro metodo permette di capire se lo stato corrente del campo di gioco è uno stato terminale (vittoria di X o vittoria di O):


Il pareggio l'ho gestito separatamente con il metodo noWhiteSpace() che restituisce true se non vi sono più spazi vuoti (quindi lo stato è DRAW).
Come vedete, qualsiasi modifica interna ad una qualsiasi di questi metodi non ha ripercussioni sull'esterno.

Analisi di TrisView.java

La GUI inizia con la dichiarazione delle seguenti variabili:



È infatti prassi comune in questo caso delegare le azioni sul model direttamente alla classe che si occupa della GUI, in modo da poter ottenere dal model i dati necessari all'aggiornamento della GUI e da aggiornare il model.



Ad ogni label personalizzato si aggiunge un listener. I parametri che riceve GridCell riguardano le coordinate dell'elemento.



Tutta l'azione si svolge qui. Grazie alle coordinate inserite in GridCell ora possiamo ottenere la posizione dell'elemento all'interno del model, e settarne il relativo valore. Grazie al valore restituito dal model sappiamo quale stato si è verificato.

Analisi di GridCell.java

Questa classe gestisce il disegno del componente - ed il ridisegno ad ogni nuovo assengnamento.

Esempio: Separare la logica dalla GUI

Di seguito il codice delle 3 classi:

TrisModel.java


TrisView


GridCell.java

Secondo Approccio: MVC

Riporterò solo le parti di codice rilevanti ai fini della spiegazione

In questo esempio ci soffermeremo sulla progettazione MVC (Model, View, Controller). La classe Model gestirà tutti gli aspetti relativi alla logica ed allo stato del programma, sarà quella che avrà - ad esempio - delle strutture dati ed altro ancora. Nel nostro caso il Model è praticamente inalterato, quindi eviterò di commentarlo.
Tutto questa volta sarà gestito con 5 classi:

• TrisModel


• TrisView


• TrisController


• GridCell


• TrisMain

Il model come già anticipato è quello di prima, vi sono solo piccole modifiche (come la scomparsa della variabile old).

Come vedremo a breve, tutto è basato su questo concetto: sul view accade qualcosa (un evento) che il Controller gestisce aggiornando anche lo stato interno (Model). Se necessario poi aggiorna anche il View con la risposta del Model... dipende dai casi insomma.

Analisi di TrisView.java

Il cambiamento al View è stato importante: gli eventi ora vengono gestiti dal Controller, quindi il View non avrà più bisogno della interface; non solo, come si sarà intuito il Controller fa da tramite tra il Model ed il View, quindi il View non ha più nemmeno bisogno di un riferimento al Model.



È cambiato inoltre anche il modo di utilizzare il JFrame. Siamo passati da is a a has a; ora TrisView non è un JFrame, ma usa (ha) un JFrame.



Il seguente metodo sarà invocato dal Controller e passerà ad esso il Listener dei componenti.

Sono stati inoltre introdotti due metodi per gestire i messaggi in arrivo dal Controller:

Analisi di TrisController.java

L'aspetto più interessante riguarda questa classe.



Nel nostro caso il model non ha bisogno di particolari inizializzazioni, il costruttore è sufficiente. Altrimenti avremmo chiamato magari un metodo di TrisModel prima di invocare l'inizializzazione della GUI che crea finestra e componenti. Ricordo che un listeners viene attaccato ad una sorgente di evento (bottoni, finestre etc) usando gli opportuni metodi addXxx; se come in questo caso la gestione dell'evento avviene all'sterno della classe della grafica, sarà sufficiente passare ad essa un riferimento. Dall'altra parte - se guardate il codice sopra - noterete infatti che il metodo makeComponent() ha come parametro un MouseListener (e TrisController implementa proprio quel listener).

L'altro aspetto che voglio far notare è come all'interno del Controller questa volta siano presenti entrambi gli oggetti. In questo modo possiamo dedurre che l'avvio dell'applicazione avvenga proprio chiamando TrisController, ma creando prima i due oggetti principali relativi al Model ed al View.

L'unico metodo di TrisController è la gestione dell'evento:



Come si può notare non differisce molto dall'implementazione precedente che aveva nel View.

Analisi di TrisMain.java

L'altra novità è TrisMain, che crea gli oggetti iniziali del Model e del View e che li passa al Controller, istanziandolo:

Esempio MVC

Di seguito il codice delle classi:

TrisModel.java


TrisView.java


TrisController.java


GridCell.java


TrisMain.java

Terzo Approccio: MVC con un proprio evento personalizzato

Il codice di questo esempio è più complesso rispetto ai precedenti. Java fornisce classi ed interfacce per gestire un tipo di situazione particolare: osservare un oggetto. E' il caso di Observer ed Observable, ad esempio. Dove un oggetto si registra come ascoltatore, ed ogni cambiamento ad uno dei dati del caso verrà notificato a chi ascolta.
In questo esempio tuttavia faremo direttamente un passo oltre. L'esempio di Observer ed Observable è comodo anche nella realtà, ma ci si può trovare di fronte ad una spiacevole situazione. Observable è una classe e deve essere estesa da quell'oggetto che verrà modificato (nel caso di specie, è il Model). Tuttavia l'inconveniente è che se la nostra classe estende già un'altra classe... questa situazione non si può gestire (Java non supporta l'ereditarietà multipla).

L'esempio citato, di Observer/Observable, è noto a chi conosce i design patterns. Infatti l'osservatore è proprio uno dei più importanti design pattern. Il caso che mostrerò rientra quindi tra questi più importanti essendo una soluzione alternativa all'implementare Observer e Observable.

Le classi che utilizza questo esempio saranno:

• TrisListener (interface)


• Coords


• TrisEvent


• TrisModel


• TrisController


• TrisView


• GridCell


• TrisMain

Come ho indicato nell'elenco, una di esse non è una classe, ma un'interfaccia.

Ciò che fa tutto questo codice lo si può riassumere così: crea un evento (TrisEvent) estendendo quelli già esistenti, crea un'interfaccia (TrisListener) estendendo quelle già esistenti, e di fatto crea un nuovo ascoltatore personalizzato.

Analisi di TrisListener.java

Questa interfaccia verrà implementata dalla classe TrisController, e fornirà solamente il metodo che essa dovrà implementare per gestire l'evento.

Analisi di Coords.java

Niente più che una classe che incapsula le coordinate di un punto (x,y) e che fornisce i relativi metodi getter/setter. Non merita di essere mostrata ora.

Analisi di TrisEvent.java

Questa classe è invece molto interessante. Incapsula tutte le informazioni generate quando si verifica un evento (generato dal Model, come vedremo tra poco). Al suo interno incapsula tutti i dati utili ad un cambio di stato:


Tutti gli eventi devono derivare da EventObject, è la superclasse di tutti gli eventi ed in effetti è seconda solo ad Object. Richiede solo "source", che è un Object, e che viene infatti passato alla superclasse invocando super().

Analisi di TrisModel.java

Questa volta la classe ha subito importanti modifiche; tra le variabili compare infatti private TrisListener trisListener;, che è un riferimento all'interfaccia che vedremo più avanti.
Anche il metodo move() è cambiato:



L'altro metodo invocato è mostrato di seguito:


In pratica accade questo: quando viene chiamato il metodo move() il codice setta la nuova mossa all'interno del campo di gioco; al termine della sua esecuzione, prima di terminare, notifica l'evento chiamando fireModelChange(). La scelta del nome è evocativa: in Java ci sono altri metodi con nomi simili che svolgono funzioni analoghe, si veda ad esempio PropertyChangeSupport.

Analisi di TrisController.java

Anche il Controller ora ha un nuovo aspetto:



Questa parte è più o meno invariata, se non nell'implementazione dell'interfaccia. Sta praticamente dicendo che anche l'evento del model (TrisListener) è gestito qui, in questa classe (ecco perchè passa this al Model).

Proseguendo nel codice della classe si troverà l'implementazione del metodo fornito dall'interfaccia:


Il Controller, ricevuto l'evento, estrae quelli che sono i dati utili alla sua elaborazione. I dati possono essere in generale N, non vi è una quantità di dati (infatti l'oggetto è totalmente personalizzato).
Presi i dati di suo interesse, notifica alla GUI l'azione da intraprendere e che rifletta lo stato interno (Il Model).

Quando avviene il click sulla GUI, l'evento viene gestito dal metodo di MouseListener, implementata appunto dal Controller:



Il metodo non fa altro che prendere l'oggetto che ha generato l'evento ed estrarne le coordinate; una volta ottenute, comunica al model quale elemento è stato clickato.
Questo come abbiamo già visto provocherà la modifica del Model e di conseguenza poi la notifica alla GUI tramite il metodo mostrato sopra.

Analisi di TrisView.java

Il View vede la comparsa di un array di GridCell, private GridCell[] cells;. Questo array ci permette di avere tutti gli elementi aggiunti alla GUI così da poter recuperare la GridCell anche dall'evento del model (passando un oggetto Coords sappiamo quale elemento deve essere aggiornato, come evidenziato da modelChanged()).
Oltre a questo mette a disposizione una serie di metodi utilizzabili dall'esterno, come quello dedicato alla vittoria di un giocatore o al pareggio.

Esempio: MVC con un proprio evento personalizzato

TrisModel.java


TrisController.java


TrisView.java


TrisEvent.java


GridCell.java



Coords.java



TrisListener.java


TrisMain.java

Conclusione

Ebbene, l'articolo è giunto al termine. Spero vi sia stato utile. Qui sotto ho lasciato 2 screenshot e l'ultimo degli esempi compilato (l'unica differenza rispetto al sorgente qui sopra è un leggero miglioramente delle coordinate di disegno oltre che alla modifica al titolo della finestra). Per eseguirlo è necessario Java 8.

Tra i 3 approcci mostrati in questo articolo io solitamente utilizzo il secondo. Il terzo - o qualcosa di analogo utilizzando Observer/Observable - risulta molto utile quando si deve aggiornare l'interfaccia rispecchiando il model (il caso di specie rientra in questa situazione, come anche i giochi in generale). Tutti e 3 gli approcci vengono utilizzati (e vi sono tanti altri approcci simili o anche differenti e basati su altri design patterns). Sicuramente la cosa da non fare è mischiare logica e grafica.


Sotto spoiler troverete due i screenshot.


Il Download del file Jar è disponibile al questo indirizzo su Mediafire: download