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!!!