È brutto per le impostazioni dell'hardcode in una classe?

Question

Ho una serie di configurazioni che, sebbene possano cambiare in futuro, la probabilità è che non dovranno mai essere modificate.

Se alcuni sono mancanti o errati, una determinata funzionalità del sistema non funzionerà correttamente.

Dovrebbero essere ancora recuperati una sorta di configurazione, xml, database ecc. E resi disponibili all'utente finale da modificare, oppure si tratta di una buona situazione in cui ha più senso codificarli in una classe che utilizza loro?

Ho passato molto tempo a cambiare continuamente idea su questo.

Answer 1

La stima del progettista della probabilità che qualcosa debba cambiare non è un criterio affidabile per prendere una decisione, perché l'uso del mondo reale dei nostri programmi ha i suoi modi peculiari di dimostrarci sbagliati.

Invece di chiedersi "quanto è probabile che qualcosa cambi?", Chiediti "ha senso che un utente finale apporti un cambiamento?" Se la risposta è "sì", rendilo modificabile dall'utente; altrimenti, rendilo modificabile solo attraverso il tuo codice.

Un particolare meccanismo attraverso il quale si rende qualcosa modificabile (un database, un file di configurazione, un file XML personalizzato e così via) non importa molto. Una cosa importante è avere impostazioni predefinite valide per le impostazioni mancanti, in modo che gli utenti finali possano avere più tempo a rompere il sistema fornendo configurazioni parziali.

Answer 2

Se le configurazioni non cambieranno mai come hai detto, allora la sua multa se dichiarerai tali proprietà come variabile nell'interfaccia o in una classe separata e userai questa costante attraverso il programma.
I file di proprietà separati vengono utilizzati solo quando alcuni valori di proprietà non sono corretti e dipendono dall'ambiente come nome del database, nome utente, password ecc. Mentre alcune proprietà sono fisse e non dipendono dall'ambiente in cui verrà distribuito come portno , se il nome del bollettino è ecc.

Answer 3

È consigliabile utilizzare qualsiasi tipo di file di configurazione o proprietà e utilizzare valori predefiniti e failsafe se il file è danneggiato/mancante. Questi approccio ha i seguenti vantaggi:

• Può essere facilmente riconosciuto come un file di configurazione che significa un altro dev non avrebbe bisogno di immergersi attraverso le classi di cambiare un parametro
file di proprietà
• può essere scritto da strumenti di compilazione come formica , quindi se hai eg un adresse server di test e di un indirizzo del server produttivo il compito formica potrebbe cambiare il contenuto di conseguenza
• funziona con valori di default, anche senza di essa

svantaggio è la complessità.

Answer 4

Dipende dalla vostra applicazione. Come linea di base, il suo buon design prevede l'uso di variabili statiche per contenere i dati di cui avrà bisogno il programma, invece di stringhe e interi di hardcoding in tutto il luogo; Ciò significa che in futuro qualsiasi modifica (ad esempio il colore del carattere wide dell'applicazione) richiederà solo un singolo cambiamento, quindi un ciclo di compilazione e tutto il necessario.

Tuttavia, se queste impostazioni sono configurabili dall'utente, non possono essere codificate in modo rigido, ma devono invece essere lette da una fonte esterna e, dove lo si fa, è una questione di progettazione, complessità e sicurezza.

I file di testo normale sono adatti per una piccola applicazione, in cui la sicurezza è scarsa e le cose sono in chiaro. L'editor di SublimeText e l'editor notepad ++ fanno questo per le loro impostazioni del tema e funziona bene. (Credo che fosse un testo normale, forse sono passati a XML ora)

Un'opzione migliore è XML, in quanto è strutturata, più facile da leggere/analizzare/scrivere. Molti progetti lo usano come opzione. Una cosa da tenere a mente sono i file corrotti, mentre li leggi/scrivendo, se l'utente chiude il programma o la JVM esce casualmente per qualsiasi motivo. Potresti voler guardare cose come i buffer. E gestisci anche FileNotFoundExceptions, se manca il file text/xml.

Un'altra opzione è un file di database di qualche tipo, è un po 'più sicuro, è possibile aggiungere la crittografia a livello di applicazione e si dispone di una moltitudine di opzioni. Grandi programmi che già utilizzano un back-end DB, come MySQL, hanno già un database a portata di mano, quindi crea una nuova tabella e memorizza lì la configurazione.Le piccole applicazioni possono guardare a SQLite come opzione.

Answer 5

Mai e poi mai codice rigido cose se hey "potrebbe" cambiare, o si potrebbe essere dispiaciuto in seguito e rendere altri matti (molto probabilmente in progetti grandi o/e open source). Se la configurazione non cambierà mai, non è più una configurazione ma una costante.

Utilizzare solo hard coding durante la sperimentazione con il codice.

Se si desidera salvare valori semplici, è possibile utilizzare le proprietà java.

Look HERE per un esempio.

buona fortuna.

Answer 6

Sì, è quasi certamente una cattiva idea codificarli; se non altro, può rendere il test (automatico o manuale) molto più difficile di quanto non sia necessario. È facile includere un file .properties nel tuo jar con i soliti valori predefiniti e cambiarli in futuro richiederebbe semplicemente di sovrascriverli in fase di runtime. Iniezione di dipendenza è di solito una scelta ancora migliore se si ha la flessibilità di organizzarlo.

Answer 7

Ci sono alcune proprietà che è possibile modificare senza dover ripetere il test del software. Queste proprietà sono state testate per un intervallo di valori o si è sicuri che è possibile modificare al massimo un riavvio. Queste proprietà possono essere configurate.

Ci sono altre proprietà che non si possono assumere funzioneranno senza ripetere il test del software. In questo caso è meglio codificarli con IMHO. Questo ti incoraggia a seguire la procedura di rilascio quando cambi questo valore. I valori che non ti aspetti di cambiare sono un buon candidato per questo.