ConwayLife Sprint2

Oltre ai requisiti già individuati nello Sprint 1, lo Sprint 2 prevede i seguenti nuovi requisiti:

1. La griglia di gioco deve essere visualizzata in una finestra Swing (anziché solo su console).
2. L'utente deve poter interagire con la griglia per:
   • Configurare lo stato iniziale delle celle tramite click del mouse.
   • Controllare l'evoluzione tramite pulsanti specifici: START, STOP e CLEAR.
3. Il sistema deve essere realizzato come evoluzione del precedente, riutilizzando la logica di dominio (il file .jar dello Sprint 1) come componente libreria.

Mi concentro sulla verifica della sostituibilità dei componenti di I/O. L'obiettivo è dimostrare che le interfacce definite nello Sprint 1 sono sufficienti a coprire i nuovi requisiti funzionali:

• L'interfaccia IOutDev rimane il contratto fondamentale. La nuova classe ConwayLifeGridClaude deve implementare tale interfaccia per poter ricevere i dati dal modello senza che quest'ultimo sia consapevole del cambiamento tecnologico (da Console a Swing).
• L'interazione tramite mouse e pulsanti viene ricondotta alle operazioni definite in GameController. La GUI agisce quindi come un Input Device che invoca metodi come onStart() o switchCellState(), confermando l'architettura reattiva analizzata in precedenza.
• Le entità ICell e IGrid non subiscono variazioni, poiché la logica di dominio (il "cosa") è indipendente dalla sua rappresentazione (il "come").

In sintesi, si conferma che l'architettura logica individuata nello Sprint 1 è chiusa alle modifiche ma aperta alle estensioni.

L'evoluzione del sistema verso una GUI Swing pone delle questioni:

• Devo utilizzare il file conway26Java-1.0.jar senza toccarne il codice, dimostrando che le interfacce dello Sprint 1 sono sufficientemente solide da supportare una nuova vista grafica senza modifiche alla logica.
• A differenza della console, la GUI genera eventi (click su celle e pulsanti). Il problema è come inviare questi comandi al LifeController. La soluzione è l'iniezione del controller nella GUI, che delega le azioni dell'utente ai metodi di GameController.
• Visto che il gioco evolve da solo in un thread separato, la GUI deve reagire ai cambiamenti del modello. Il metodo displayGrid agisce come punto di contatto: ogni volta che il controller lo chiama, la GUI deve ridisegnare la griglia (repaint).

Ho due obiettivi di testing in questa fase:

1. esecuzione dei test JUnit dello Sprint 1 per garantire che l'introduzione della GUI non abbia alterato la correttezza della logica di dominio (Life, Grid, Cell).
2. verifica per accertarsi che:
   • il click sulla cella della GUI invochi correttamente switchCellState sul Controller
   • la pressione dei tasti START/STOP attivi o metta in pausa il thread di evoluzione
   • il comando CLEAR resetti visivamente la griglia dopo aver pulito il modello

Il progetto di questo sprint realizza l'evoluzione del sistema come composizione di componenti:

• La logica di dominio non è stata riscritta. Utilizzo il file conway26Java-1.0.jar (prodotto nello Sprint 1) come libreria esterna, importata nel build.gradle.
• Implemento la classe ConwayLifeGridClaude.java, che estende JFrame e implementa IOutDev, agendo sia come visualizzatore della griglia che come sorgente di input per l'utente.
• Il nuovo MainConwayLifeJava.java configura il sistema iniettando il riferimento della GUI nel LifeController. Per permettere alla GUI di inviare comandi (Start/Stop/Click), viene effettuata una back-injection del controller nella GUI tramite il metodo setController.