DOMANDA java - esercizio con più classi

[petrusic]

Ho ripreso a studiare Java tramite Eclipse e ho finito le prove di base su un esercizio, da riga di comando, dove ho realizzato un menù principale e 3 sottomenù.
Funziona perfettamente.
In questa prima fase le scelte finali (quelle da sottomenù) producono soltanto un riga di output nella console

********************************************************************************
********************************************************************************
Menu iniziale
.....
0 - Fine Lavoro
1 - Inserimento Dati
2 - Uscite Numeri miei
3 - Utilità
--------------------------------------------------------------------------------
digita il numero del menu' scelto
3
********************************************************************************
********************************************************************************
Sottomenu' 3 - Utilità:
.....
0 - Annulla Scelta
1 - Caricamento/Modifica Numeri Giocabili
2 - Generazione Sistema
3 - Aggiornamento quote monetarie fisse
--------------------------------------------------------------------------------
digita il numero del menu' scelto
1
menu selezionato = 3.1 - Caricamento/Modifica Numeri Giocabili
********************************************************************************
********************************************************************************
Sottomenu' 3 - Utilità:
.....
0 - Annulla Scelta
1 - Caricamento/Modifica Numeri Giocabili
2 - Generazione Sistema
3 - Aggiornamento quote monetarie fisse
--------------------------------------------------------------------------------
digita il numero del menu' scelto
4f
------- scelta non valida -------
digita il numero del menu' scelto
0
********************************************************************************
********************************************************************************
Menu iniziale
.....
0 - Fine Lavoro
1 - Inserimento Dati
2 - Uscite Numeri miei
3 - Utilità
--------------------------------------------------------------------------------
digita il numero del menu' scelto
0
Fine lavoro

Tutte le righe di stampa devono diventare un richiamo ad una classe contenente il codice relativo.
Ho pensato alla generazione di classi e non di metodi, perchè credo che sia più logico, in vista di dell'implementazione della GUI che in questo momento sconosco in toto.
Vorrei pertanto conoscere il parere di chi ha eseprienza nella realizzaziome di GUI, tendo presente che l'attuale IDE che ho dovuto mettere in uso per mettere in pratica lo studio di Java, è "eclipse".

 

[Andretti60]

Non e' molto chiaro quello che stai chiedendo.
Prima di tutto un programma con GUI funziona in maniera molto diversa che uno con un menu' da terminale.
Quindi devi progettare e scrivere le tue classi in base alla funzionalita' del tuo programma, indipendentemente che sia da terminale o con GUI.
Nel tuo caso per esempio hai una serie di menu che vengono visualizzati in base alla scelta dell'utente, mentre invece da una applicazione GUI tutti i menu saranno disponibili nel menu principale.

 

[petrusic]

Non e' molto chiaro quello che stai chiedendo.
Prima di tutto un programma con GUI funziona in maniera molto diversa che uno con un menu' da terminale.

Questo lo so benissimo. Ho voluto dare l'impostazione a menù solo per creare una logica da riprendere e riscrivere quando potrò finalmente scrivere dentro la GUI.

Quindi devi progettare e scrivere le tue classi in base alla funzionalita' del tuo programma, indipendentemente che sia da terminale o con GUI.
Nel tuo caso per esempio hai una serie di menu che vengono visualizzati in base alla scelta dell'utente, mentre invece da una applicazione GUI tutti i menu saranno disponibili nel menu principale.

Ma anche io ho scritto tutto il menù dentro il metodo main della classe principale, per farlo funzionare, per ora, senza la gestione eventi.
Quello che penso di riportare all'interno della gestione eventi della GUI è questo:
Cliccando sul menù principale, composto da 4 pulsanti (Fine Lavoro | Inserimento Dati | Uscite Numeri miei | Utilità), dovrò aprire la tendina sottostante (sottomenù) con le sue righe di scelta. Cliccando questa volta su una delle righe del sottomenù, dovrei avviare, secondo me, la chiamata alla classe relativa alla scelta schedulata (Es. Caricamento/Modifica Numeri Giocabili).

Se quello che voglio dire ora è chiaro e se ho visto bene, pensando alla chiamata della classe "Caricamento/Modifica Numeri Giocabili", dovrei sin da subito, secondo quanto capito, scrivere un file classe (Es. NumGiocabili) che dovrebbe appartenere allo stesso progetto, ma che costituisce un package distinto. E ciò vale per ciascun tipo di scelta (di sottomenù) che da utente farò.
É così?

 

[Andretti60]

Intendi scrivere una classe per ogni elemento dei menu?
Mi pare eccessivo, in genere le classi si scrivono raggruppando metodi che operano sullo stesso insiemi di dati.

Ma qui si entra un po' troppo nel generale, ossia come progettare una applicazione che risponde ad azioni dell'utente (che e' poi indipendente dal linguaggio e dal IDE che vengono usati). Che non e' facile in quanto dipende dal paradigma che si intende utilizzare.

La prima cosa da fare e' comunque progettare la classe (o la gerarchia di classi) che leggono i dati da dove sono memorizzati (per esempio in un database, in un file, da un sito internet) e li mettono in memoria (se sia possibile), "esponendo" poi i dati in maniera logica in modo che possano essere poi manipolati dall'utente ed eventualmente poi memorizzati nuovamente (o esportati). Quello e' il primo passo (in qualsiasi applicazione).

 

[petrusic]

Intendi scrivere una classe per ogni elemento dei menu?
Mi pare eccessivo, in genere le classi si scrivono raggruppando metodi che operano sullo stesso insiemi di dati.

Il programma è effettivamente abbastanza contenuto.
Quello che non so è la differenza che passa fra un programma scritto tutto in unica classe o distribuito in più classi, una per ciascuna funzione selezionata dall'utente finale.
Infatti, se le classi non vengono caricate in memoria tutte insieme, all'avvio del programma, ma al momento del richiamo, allora, per occupare meno memoria, sarebbe più opportuno distribuire il programma in più classi, se invece, concentrare il codice tutto dentro una classe o distribuirlo in più classi, dal punto di vista di dispendio di memoria, è la stessa cosa, allora potrei riunire tutto il codice dentro la stessa , unica classe.

La prima cosa da fare e' comunque progettare la classe (o la gerarchia di classi) che leggono i dati da dove sono memorizzati (per esempio in un database, in un file, da un sito internet) e li mettono in memoria (se sia possibile), "esponendo" poi i dati in maniera logica in modo che possano essere poi manipolati dall'utente ed eventualmente poi memorizzati nuovamente (o esportati). Quello e' il primo passo (in qualsiasi applicazione).

Se ti stai riferendo alla progettazione del programma, posso dirti che l'analisi tecnico-funzionale del programma è già realizzata e che quindi ho già pensato ai passi di realizzazione della procedura, a partire dalla creazione del piccolo database occorrente.
L'importante per me è partire col piede giusto:

scrivo tutto in una classe o frammento il codice in più classi, per contenere, secondo la mia logica, l'impegno di memoria, come ho descritto dettagliatamente prima.

 

[fabio93]

Le classi andrebbero stabilite in base alla responsabilità, cioè ogni classe dovrebbe avere un compito ben specifico.
Una tassonomia accademica prevede di suddividere le classi in tre categorie: entità, confine e controllo. Le classi entità modellano gli attori del dominio dell'applicazione (ad es.: Studente, Impiegato, Conto corrente, Automobile). Le classi di confine si occupano dell'interfaccia con l'"esterno", dove quest'ultimo può essere ad esempio l'utente o un altro programma o un servizio web o un db (ad esempio anche una classe che realizza una GUI). Infine, le classi di controllo si occupano di gestire la logica dell'applicazione, e quindi le relazioni tra le prime due, e ad esempio anche la gestione delle eccezioni. Ovviamente si tratta di una classificazione teorica e non è detto che ciascun software necessiti di classi per ciascun tipo, cosiccome non è scontato che ciascuna classe possa rientrare pienamente in una di queste categorie.
Più in generale, direi che potresti procedere così: una volta stabilito cosa deve fare il software, dovresti essere in grado di suddividere logicamente le sue componenti in base al loro compito e tradurre questa suddivisione logica in classi.
Avere una classe per ogni metodo, come mi pare tu voglia fare, è inusuale, o meglio, ci possono essere benissimo classi con un solo metodo, ma attribuire metodi simili a classi diverse potrebbe essere frammentario. Dovresti progettare le classi che si occpano del backend senza pensare alla UI, ad esempio dotandole di metodi che possano essere chiamati dalla classe che si occuperà della UI. In questo caso, il menù sarà implementato nella classe della GUI, non suddiviso in tutte le classi.
La progettazione Object Oriented non è cosa semplice e ci sono tanti principi che si possono applicare (principi SOLID, Design Pattern) ma ora sarebbe troppo prematuro parlarne, gli ho menzionati più che altro perché tu possa guardarli con calma quando vorrai.
Per quanto concerne le prestazioni, direi che per ora non devi preoccupartene. In generale, salvo necessità particolari, non si dovrebbe sacrificare una buona ingegnerizzazione (che significa anche meno bug e più facilità di manutenzione ed estensione) in nome delle prestazioni, anche perché nel tuo caso si tratta di un software talmente semplice che non noteresti alcuna differenza.

 

[petrusic]

Le classi andrebbero stabilite in base alla responsabilità, cioè ogni classe dovrebbe avere un compito ben specifico.
Una tassonomia accademica prevede di suddividere le classi in tre categorie: entità, confine e controllo. Le classi entità modellano gli attori del dominio dell'applicazione (ad es.: Studente, Impiegato, Conto corrente, Automobile). Le classi di confine si occupano dell'interfaccia con l'"esterno", dove quest'ultimo può essere ad esempio l'utente o un altro programma o un servizio web o un db (ad esempio anche una classe che realizza una GUI). Infine, le classi di controllo si occupano di gestire la logica dell'applicazione, e quindi le relazioni tra le prime due, e ad esempio anche la gestione delle eccezioni. Ovviamente si tratta di una classificazione teorica ...

Dalle mie parti esiste un proverbio che dice "ogni testa è un tribunale". Tradotto nella relatà di cui parliamo si tradurrebbe in : lo stesso problema può essere affrontato in modo diverso, secondo l'impostazione personale che ciascuno puo dare alla logica organizzativa della percorrenza da applicare. Alla fine si ottiene lo stesso risultato: il trattamento corretto dei dati che, partendo da una status consolidato, esegue aggiunte, modifiche e sottrazioni, producendo una nuova dimensione finale.

E siccome mi sto affidando ad un nuovo linguaggio, deve cambiare anche il mio modus operandi. Farò del mio meglio.

A prescindere dal ragionamento teorico, mi resta da capire come devo procedere per scrivere il mio modesto progettino agganciandovi più oggetti classe. Nello studio che sto seguendo, non ho incontrato ancora l'argomento relativo.

 

[fabio93]

oggetti classe

Probabilmente lo sai già, ma oggetto e classe sono due cose diverse: un oggetto è un'istanza di una classe, un esemplare per così dire.
Oggetto : classe = Pluto : cane, per capirci.
Ci possono essere classi che si usano senza istanziarne oggetti, si parla in tal caso di classi statiche, anche se in Java (tranne per le inner class, ovvero classi definite all'interno di un'altra) tecnicamente non esistono le classi statiche nel senso che non puoi dichiarare una classe 'static', ma puoi dichiarare static singoli metodi o attributi.
Se un attributo è static, sarà condiviso da tutti gli oggetti di quella classe (una copia per tutti). Un esempio potrebbe essere un contatore che conta il numero degli oggetti istanziati.
Se un metodo è static, sarà un metodo di classe, ovvero potrà essere invocato senza istanziare un oggetto della classe di appartenenza (con l'operatore 'new'), e potrà modificare solo gli attributi static della classe.
Tornando al discorso delle prestazioni, se una tua classe non necessita di essere istanziata, cioè se non ti servono tanti oggetti, potrebbe essere una buona idea renderla statica, in questo modo ad esempio per i metodi verrà adottato lo static binding, cioè il legame tra il nome del metodo (alla sua invocazione) e la sua definizione avverrà durante la compilazione, invece che a run time, ottenendo un beneficio prestazionale.

 

[Andretti60]

Tieni presente che a meno che una classe non si crei e si distrugga ogni pochi millisecondi, la creazione di una classe non influisce minimamente sul tempo di esecuzione di programma. In genere le classi si creano quando vengono letti i dati, poi esistono finche' non si chiude il programma. Lo stesso per la memoria ,a meno che ogni classe tenga una copia dei dati (cosa che NON VA assolutamente fatta) alla fine la memoria che occupa il programma non dipende da quante classi e' composto. DI fatto poi una "classe" non occupa nessuna memoria, solo le "instanze" di una classe quando vengono create. In genere non si guarda troppo sul numero delle classi che si creano, se ne creano quante se ne hanno bisogno. DI fatto e' sempre meglio averne tante e ognuna specializzata per il suo scopo. La classe principale (il Main nel tuo caso) di fatto non dovrebbe fare assolutamente nulla se non instanziare le varie classi e lasciare che siano poi loro a fare il loro lavoro. Solo in questa maniera hai un programma che e' facile da comprendere, capire, modificare e farne il debug. L'importante poi che ogni classe sia una "isola" a se stante, senza conoscenza di altre classi, nel rispetto della gerarchia; per esempio se una classe ha una collezione di dati definiti in altri classi, ovvio che ne debba avere conoscenza. MAI e poi MAI avere classi con conoscenza dei componenti GUI. Lo scopo e' di avere codice che sia usabile e ri-usabile in altri contesti. E' insomma lo stesso concetto che si applicava alle "librerie" di uso generico prima della programmazione ad oggetti (ovvio poi che le librerie possono essere create, anzi vanno create, anche nella programmazione ad oggetti.