[OT] Consigli per una buona strutturazione del software Java

[franksisca]

Mi capita molte volte di leggere discussioni che mi sembrano "volte" sempre ad una mal strutturazione del software, perchè molte volte alcuni (anche io) iniziano a sviluppare un applicativo senza prima mettersi a ragionarci sopra.

Possiamo, in linea generale, tracciare delle linee guida per avere un software comunque "strutturato" decentemente?

io credo che un software per avere delle linee guida generali decenti, debbA:

1) Rispettare il pattern MVC. ovvero gli oggeti delegati al loading/saving dei dati devono essere indipendenti dal resto dell'applicazione

2) se si interagisce con immagini e file esterni, usare il getresource (o getresourceAsStream) e mettere i file all'interno della cartella che contine i .class, altrimenti in fase di esportazione non vengono portati all'interno dello stesso

3) se si caricano dati allo startup, o in fase di esecuzione, usare dei thread per il loading, si alleggerisce il software stesso e si rende la GUI più leggere (niente più pulstanti che restano premuti mentre si apre un file)

4) usare nomi varieabili/metodi/classi autoesplicanti ma non troppo.
La classe "PersonaSenzaCodiceFiscale" è prolisso...mentre "PersonaSenzaCF" va già meglio

5) commentare i metodi più complessi per le generazioni future.

6) set e get OVUNQUE

7) non mettere a tacere le eccezioni MAI

8) Divide et Impera sempre e comunque...siamo ad oggetti, sfruttiamoli!!!

9) Swing va bene, non AWT, ma Swing...

10) Usare le interfaccie per rendere gli oggetti "estendibili" per futuri aggiornamenti.

Queste sono alcune idee che mi sono fatto e che vorrei voi confermaste/confutaste. Sono aperto ad ulteriori critiche

[valia]

Originariamente inviato da franksisca
Mi capita molte volte di leggere discussioni che mi sembrano "volte" sempre ad una mal strutturazione del software, perchè molte volte alcuni (anche io) iniziano a sviluppare un applicativo senza prima mettersi a ragionarci sopra.
Possiamo, in linea generale, tracciare delle linee guida per avere un software comunque "strutturato" decentemente?

Sono linee guida molto generali, ma che cmq devi adattare alle situazioni. Alcune cose non valogno in assoluto o non devi mettercele per forza

Originariamente inviato da franksisca
io credo che un software per avere delle linee guida generali decenti, debbA:

1) Rispettare il pattern MVC. ovvero gli oggeti delegati al loading/saving dei dati devono essere indipendenti dal resto dell'applicazione

2) se si interagisce con immagini e file esterni, usare il getresource (o getresourceAsStream) e mettere i file all'interno della cartella che contine i .class, altrimenti in fase di esportazione non vengono portati all'interno dello stesso

e chi lo dice?
Io ho un sacco di risorse per cui viene dato il path assoluto.
Questo si fa quando vuoi includere le tue risorse all'interno del jar, ma se io strutturo tutto a livello di cartella (con resoruce e tutto il resto) e faccio in modo che alla mia app arrivi sempre la base dir, ho bisogno di usare getResource? No.
Se l'utente mi fornisce delle risorse, le carichi passando per il classloader? No.
Considera sempre quello che devi fare.

Originariamente inviato da franksisca
3) se si caricano dati allo startup, o in fase di esecuzione, usare dei thread per il loading, si alleggerisce il software stesso e si rende la GUI più leggere (niente più pulstanti che restano premuti mentre si apre un file)

Anche qui nì, perché se i dati di startup servono a prendere uno stato consistente, che fai sblocchi lo stato e se richiedi operazioni (cosa possibile) non fai niente perché non sei in stato consistente?
Valuta sempre, al massimo devi cercare di ottimizzare queste fasi, in modo da farle durare il meno possibile (pena qualche richiesta in più al db)

Originariamente inviato da franksisca
4) usare nomi varieabili/metodi/classi autoesplicanti ma non troppo.
La classe "PersonaSenzaCodiceFiscale" è prolisso...mentre "PersonaSenzaCF" va già meglio

5) commentare i metodi più complessi per le generazioni future.

6) set e get OVUNQUE

7) non mettere a tacere le eccezioni MAI

8) Divide et Impera sempre e comunque...siamo ad oggetti, sfruttiamoli!!!

9) Swing va bene, non AWT, ma Swing...

10) Usare le interfaccie per rendere gli oggetti "estendibili" per futuri aggiornamenti.

Queste sono alcune idee che mi sono fatto e che vorrei voi confermaste/confutaste. Sono aperto ad ulteriori critiche

non è un must, ma sono preferibili. Nomi esplicativi vanno bene, anche se lunghi, devi sempre capire cosa fai. Da PersonaSenzaCodiceFiscale a PersonaSenzaCF nn cambia molto, da a a PersonaSenzaCF è un altro mondo.
I commenti vanno sempre inseriti, non vuole dire che ogni istruzione devi commentarla, devi solo ricordare di spiegare a grandi linee cosa fai.
Sui get e set ovunque si aprono migliaia di dibattiti, valuta sempre cosa fai, in alcuni casi non ne hai bisogno (o devi renderli invisibili).
Chi ti dice che non devi mettere a tacere le eccezioni? Puoi "loggare" l'evento, ma fregartene altamente. Sempre senso critico, dove ti trovi in uno stato inconsistente blocca tutto, dove puoi recuperare recupera e traccia. Non è bello che l'utente generico veda ogni piccolo problema che si presenta.

Le interfacce non vengono usate con quello scopo, una buiona progettazione non blocca l'estensione di un oggetto. Non mi sognerei mai di definire una gerarchia di classi per interfacce, quando inizio a metterne troppe è segno di confusione nella progettazione e inutile intrecciamento.
Io aggiungerei che bisogna essere il più possibili lineari, cosa molto molto difficile

[franksisca]

Originariamente inviato da valia
Sono linee guida molto generali, ma che cmq devi adattare alle situazioni. Alcune cose non valogno in assoluto o non devi mettercele per forza


e chi lo dice?
Io ho un sacco di risorse per cui viene dato il path assoluto.
Questo si fa quando vuoi includere le tue risorse all'interno del jar, ma se io strutturo tutto a livello di cartella (con resoruce e tutto il resto) e faccio in modo che alla mia app arrivi sempre la base dir, ho bisogno di usare getResource? No.
Se l'utente mi fornisce delle risorse, le carichi passando per il classloader? No.
Considera sempre quello che devi fare.

Anche qui nì, perché se i dati di startup servono a prendere uno stato consistente, che fai sblocchi lo stato e se richiedi operazioni (cosa possibile) non fai niente perché non sei in stato consistente?
Valuta sempre, al massimo devi cercare di ottimizzare queste fasi, in modo da farle durare il meno possibile (pena qualche richiesta in più al db)



non è un must, ma sono preferibili. Nomi esplicativi vanno bene, anche se lunghi, devi sempre capire cosa fai. Da PersonaSenzaCodiceFiscale a PersonaSenzaCF nn cambia molto, da a a PersonaSenzaCF è un altro mondo.
I commenti vanno sempre inseriti, non vuole dire che ogni istruzione devi commentarla, devi solo ricordare di spiegare a grandi linee cosa fai.
Sui get e set ovunque si aprono migliaia di dibattiti, valuta sempre cosa fai, in alcuni casi non ne hai bisogno (o devi renderli invisibili).
Chi ti dice che non devi mettere a tacere le eccezioni? Puoi "loggare" l'evento, ma fregartene altamente. Sempre senso critico, dove ti trovi in uno stato inconsistente blocca tutto, dove puoi recuperare recupera e traccia. Non è bello che l'utente generico veda ogni piccolo problema che si presenta.

Le interfacce non vengono usate con quello scopo, una buiona progettazione non blocca l'estensione di un oggetto. Non mi sognerei mai di definire una gerarchia di classi per interfacce, quando inizio a metterne troppe è segno di confusione nella progettazione e inutile intrecciamento.
Io aggiungerei che bisogna essere il più possibili lineari, cosa molto molto difficile

grazie per la critica costruttiva.

in effette le tue considerazioni sono più che valide, ed in effetti creare un "struttura lineare" è praticamente impossibile dato la varietà di situazioni in cui ci si potrebbe trovare. i miei volevano essre dei suggerimenti e linee guide per chi sviluppa standalone. ovviamente sono da affiancare alle tue considerazioni che ripeto sono molto valide.

Solo alcuni puntualizzazioni:

Chi ti dice che non devi mettere a tacere le eccezioni? Puoi "loggare" l'evento, ma fregartene altamente. Sempre senso critico, dove ti trovi in uno stato inconsistente blocca tutto, dove puoi recuperare recupera e traccia. Non è bello che l'utente generico veda ogni piccolo problema che si presenta.

intendevo proprio questo...fare il logging per me "equivale" a non metterla a tacere. il concetto è quello che volevo dire io, ma tyu lo hai spiegato meglio

Le interfacce non vengono usate con quello scopo, una buiona progettazione non blocca l'estensione di un oggetto. Non mi sognerei mai di definire una gerarchia di classi per interfacce, quando inizio a metterne troppe è segno di confusione nella progettazione e inutile intrecciamento.

si, non sono fatte per quelle ma danno una mano. ovviamente non bisogna abusarne e ovviamente deve esserci una buona progettazione dietro.

Io aggiungerei che bisogna essere il più possibili lineari, cosa molto molto difficile

si, questo è fondamentale!!!

[valia]

la linearità tendi a raggiungerla con un po' di esperienza, quando capisci bene come organizzare le cose, di solito quando piangi per giorni perché non capisci le intersezioni del codice e ti riprometti (seguendo la tua promessa) di scrivere quello che arriva meglio.
Quando scrivo (o faccio le cose) di solito se mi trovo "incartata" già a livello teorico è segno che sto andando nella direzione sbagliata

Il resto bon, senso critico SEMPRE e alla fine non c'è UNA soluzione assoluta, ma una soluzione che va bene al tuo caso

[schumy2000]

Originariamente inviato da franksisca

9) Swing va bene, non AWT, ma Swing...

io uso Swing a livello di componenti (JButton, JTable, JTextField etc etc)
però a livello di Eventi uso la java.awt.Event e non mi sono mai trovato male

[LeleFT]

Originariamente inviato da schumy2000
però a livello di Eventi uso la java.awt.Event e non mi sono mai trovato male

Anche perchè quelli sono... non ce ne sono altri.

I componenti Swing sono tutti (o quasi) estensione dei componenti AWT. Gli eventi, di conseguenza, sono quelli del package AWT. Quello che l'autore del post intendeva dire è che non è buona norma utilizzare direttamente i componenti AWT, ma di appoggiarsi direttamente su quelli Swing.

Una cosa la aggiungo io: mai mescolare componenti Swing con componenti AWT. I risultati sono inaspettati.


Ciao.

[Scara95]

Per quanto riguarda la struttura e l'organizzazione del codice, io consiglio di applicare i principi fondamentali del linguaggio Eiffel a ogni linguaggio (specialmente quelli ad oggetti).
Edit:Molto importante è a mio parere l'uniform-acess principle
P.s. linko wikipedia, i principi fondamentali sono scritti all'inizio: desing by contract ...