Un' architettura a strati semplice ha:
- uno strato per l'interfaccia utente
- e uno strato del dominio
Gli attori, come l'osservatore umano in Monopoly, generano degli eventi UI, come cliccare su un pulsante con il mouse per avviare la partita. Gli oggetti della UI devono poi reagire all'evento generato dall'utente per dare effettivamente inizio alla partita.
In base al modello MVC (Model-View-Controller: Modello-Vista-Controller) gli oggetti della UI non devono contenere logica applicativa o di business, come per esempio calcolare la mossa di un giocatore. Per cui una volta che gli oggetti della UI rilevano l'evento del mouse, devono delegare la richiesta agli oggetti di domino nello strato del dominio.
Il pattern Controller risponde a questa domanda: qual è il primo oggetto, oltre lo strato della UI, che deve ricevere il messaggio dello strato dell'interfaccia utente?
Nel caso del Monopoly e del diagramma di sequenza del caso principale abbiamo:
l'operazione chiave è playGame. L'osservatore umano genera una richiesta playGame (probabilmente cliccando su un pulsante dell'interfaccia grafica) e il sistema risponde.
La figura illustra nel dettaglio cosa succede esattamente, ipotizzando che la UI del sistema usi Swing con una finestra JFrame e un bottonre JButton.
L'osservatore clicca su "Press to play", viene catturato l'evento actionPerformed di JButton che deve essere gestito nell'interfaccia utente e quindi essere inviato ad una classe del dominio: ma quale?
La classe di cui stiamo parlando è il Controller. Il Controller connette lo strato di interfaccia utente con lo strato di dominio. Il controller coordina e controlla la gestione delle richieste.
Tabella riassuntiva del pattern...
| Nome | Controller |
|---|---|
| Problema | Qual è il primo oggetto oltre lo strato UI a ricevere e coordinare ("controllare") un'operazione di sistema? |
| Soluzione | Assegnare la responsabilità a un oggetto che rappresenta una delle seguenti scelte: |
| a) | Rappresenta il "sistema" complessivo: un oggetto che rappresenta l'ingresso al modello di dominio, un dispositivo all'interno del quale viene eseguito il software. |
| b) | Rappresenta uno scenario di un caso d'uso all'interno del quale si verifica l'operazione di sistema (un controller di caso d'uso o di sessione) |
Nel caso di Monopoly possiamo scegliere:
- un oggetto che rappresenta il "sistema" complessivo o un "oggetto radice", per esempio un oggetto chiamato MonopolyGame;
- un oggetto che rappresenta un dispositivo all'interno del quale è eseguito il software; questa opzione si riferisce ai dispositivi hardware creati ad hoc, tale opzione non è applicabile in questo caso;
- un oggetto che rappresenta il caso d'uso o la sessione in cui si verifica tale evento. Per esempio una classe PlayMonopolyGameHandler.
L'aggiunta handler alla fine di PlayMonopolyGameHandler non è un caso. Quando si hanno più controller, per esempio per casi d'uso, si deve indicare che esso è un controller aggiungendo alla fine handler o session.
L'opzione 1: avere un solo controller in tutto il sistema è utile se ci sono poche operazioni di sistema. Altrimenti diventa più ideale l'opzione 2.