Domanda

Esiste una raccolta di linee guida di progettazione comunemente controllate per separare le classi di modelli dalle classi di vista/controller in un'app Java Swing? Non sono così preoccupato che la vista/controller non sappia nulla del modello come il contrario: vorrei progettare il mio modello per non avere conoscenza di nulla in Javax.swing. Idealmente dovrebbe avere una semplice API che gli consente di essere guidata da qualcosa di primitivo come una CLI. Dovrebbe essere, vagamente parlando, un "motore".

Comunicare gli eventi della GUI al modello non è troppo difficile: gli artisti possono chiamare l'API del modello. Ma che dire di quando il modello apporta i propri cambiamenti di stato che devono essere riflessi alla GUI? Questo è ciò per cui "ascoltare", ma anche "essere ascoltato" non è del tutto passivo; Richiede che il modello sia a conoscenza dell'aggiunta di un ascoltatore.

Il problema particolare che mi ha fatto pensare implica una coda di file. Sul lato della GUI c'è un DefaultListModel Dietro a JList, e ci sono alcune cose GUI da scegliere i file dal file system e aggiungerli alla JLIST. Sul lato del modello, vuole estrarre i file dalla parte inferiore di questa "coda" (facendoli scomparire dalla jlist) ed elaborarli in qualche modo. In effetti, il codice modello è già scritto: attualmente mantiene un ArrayList<File> ed espone un pubblico add(File) metodo. Ma sono in perdita su come far funzionare il mio modello con la vista/controller senza alcune modifiche pesanti e specifiche per l'oscillazione al modello.

Sono molto nuovo per la programmazione di Java e GUI, avendo sempre fatto la programmazione "batch" e "back-end" fino ad ora-da cui il mio interesse a mantenere una rigorosa divisione tra modello e interfaccia utente, se possibile e se può essere insegnato.

Nessuna soluzione corretta

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top