Dove mettere le variabili necessarie tra le classi?

Question

Dove mettere le variabili necessarie tra le classi?

#1 da (1 voti)

0

Ho 3 classi: un'estensione JButton, FButton; un JTextField; e un'estensione JPanel, FPanel, che conterrebbe un'istanza di entrambi.

L'FButton dovrebbe aprire un file e rendere disponibili il nome e la directory del file per il file.

Il JTextField ha lo scopo di visualizzare il nome del file e la directory forniti da FButton.

Ho capito che FPanel dovrebbe essere quello contenente il nome e la directory del file. Se faccio FButton e JTextField classi private di FPanel, problema risolto con variabili pubbliche. Che ne dici se voglio separarli in una classe pubblica di FPanel, una classe FButton visibile del pacchetto e una classe JTextField visibile nel pacchetto, all'interno dello stesso pacchetto? Come posso rendere le variabili di file disponibili per tutte le classi nel pacchetto?

Dovrei farlo in quel modo?

java packages swing

posta user2738698 28.03.2014 - 17:56

fonte

1 risposta

Leggi altre domande sui tag java packages swing

Caricamento dinamico della libreria MPL nell'applicazione closed source Preferenza per vedere se il valore di un campo è stato modificato js o linq object?

score 1 · Accepted Answer

Penso che la difficoltà si presenti perché hai gli oggetti di visualizzazione (Swing) che memorizzano lo stato dell'applicazione. In un'applicazione desktop, so che il controller e la vista a volte vengono unificati parzialmente o interamente, ma il modello dovrebbe essere ancora separato.

Durante lo sviluppo di tali applicazioni, mi piace utilizzare il seguente approccio:

Alcuni codici (che potrebbero essere principali, un listener di eventi, qualunque cosa) attivano una nuova vista nell'esistenza.
Una factory di qualche tipo costruisce gli elementi MVC:
1. Visualizza: preferisci utilizzare le classi Swing standard e assemblarle insieme.
2. Modello: crea un oggetto per gestire uno di due tipi di dati. Uno, stato persistente che è stato probabilmente trasmesso dal controllore allegato. Due, stato che viene utilizzato da questa nuova vista (oggetti temporanei che possono essere condivisi).
3. Controller: costruisce più ascoltatori e li collega agli oggetti vista. Avranno anche in genere riferimenti agli oggetti del modello in modo che possano agire su di essi.
Avanti, collega tutto. Aggiungi ascoltatori alla vista. Usa gli oggetti comuni tra di loro quando appropriato, in modo che possano vedere gli stessi dati e aggiornare la vista secondo necessità.

Credo che tu stia facendo la domanda sbagliata: usare l'approccio sopra può essere in grado di risolvere il tuo dilemma (non posso dire con certezza, non vedo il tuo codice).

Ho anche altamente consiglio di evitare variabili globali, stato statico, ecc. Mi piace creare Context oggetti che contengono stato applicabile all'intera applicazione o porzione di esso che normalmente sarebbe una "variabile globale "a uno sviluppatore meno esperto. Questo contesto contiene solo le variabili che sono veramente necessarie per essere condivise tra gli oggetti, come il file corrente (o l'astrazione del file), l'utente registrato o altro stato che può influenzare legittimamente tutti gli oggetti in un'applicazione o in un modulo.

Ridurre l'accoppiamento in questo modo rende i singoli elementi più riutilizzabili. Mentre il codice può essere più prolisso e (inizialmente) difficile da seguire, lo semplifica e lo rende più semplice alla fine. Ricorda i tuoi principi SOLID .