ed è sbagliato.Originariamente inviata da paulinho
All'implementazione che risolve il problema produttore/consumatore NON deve interessare di come ci si interfaccia con il mondo esterno. E' indifferente se leggi i dati da file, da console, da un altro stream oppure da grafica.
Se tu aggiungi nel costruttore di produttore e consumatore i componenti grafici (per farci delle setText) stai di fatto creando un legame che non esiste, bypassi la logica ad oggetti e se fossi il revisore del tuo esercizio, io lo considererei errato.
Ti è stato già suggerita la soluzione: l'observable. Quello che ti si suggerisce è che la tua applicazione crea un evento e dice "mondo io ho messo un messaggio". Il componente grafico (ma capisci bene che gestire il tutto con un componente grafico è un dettaglio) si registra come "ascoltatore" di questo evento e quando verrà creato, lui saprà come gestirlo.
IN parole povere hai:
1. EventMessage, classe che modellizza l'evento (ho mandato un messaggio/devo ricevere un messaggio
2. Interfaccia EventMessageListener, avrà quando meno un metodo handle (MessageEvent) che gestisce il messaggio
3. Classe che implementa questa interfaccia. Bada bene che può anche essere la classe che estende JFrame, questa sa chi ha dentro e sa come aggiornarsi. Se l'output fosse su file, la classe che gestisce l'output implementerà tale interfaccia, garantendo la scrittura su file
4. EventManager, gestore degli eventi, tiene conto di chi si è registrato in ascolto di tale evento e scatena l'azione.
Di esempi di applicazioni con eventi custom ce ne sono tanti in rete, usa google e non è difficile
Rispondi quotando