Utilizzo di una classe di configurazione (per tutte le costanti / Magic)

Question

Utilizzo di una classe di configurazione (per tutte le costanti / Magic)

#1 da (5 voti)
#2 da (4 voti)

4

Vengo da uno sfondo in cui l'utilizzo di un file di configurazione per ogni, se non ogni, costante è la migliore soluzione per la manutenibilità e la flessibilità del programma. Con questo intendo, ogni stringa codificata, intero, tabella / matrice, booleana, colore, espressione di formattazione, ecc. Sono tutti messi in un solo file o classe (spesso chiamata la classe "Configurazione").

Un grande vantaggio di questa soluzione è che le modifiche al codice "accidentale" del futuro sono in grado di introdurre nuove "caratteristiche" quando viene modificata una classe principale o un blocco di codice. Trovo che gli sviluppatori escano dalle aree del codice che non dovrebbero essere toccati senza pensarci davvero. Rende anche un codice in una classe o sezione principale molto più leggibile e coerente (vedi sotto):

if (x == 5)
{
    // Logic here
}

Versus

if (x == Config.MaxNumberOfResults)
{
    // Logic here
}

più tardi è MOLTO più leggibile e coerente (specialmente in futuro) e richiede pochi o nessun commento da mantenere e nessuna logica deve essere riscritta se decidiamo di volere un massimo massimo di risultati.

Il problema con il codice precedente è che qualche altro sviluppatore potrebbe alla fine capire che 5 è il limite massimo del risultato e poi penso di volere qualcosa di diverso da quello (qualche tentativo dopo) che includono quel numero (perché dio-proibito cambiando il numero) inserendo quindi > = ora l'intero blocco di codice cambia ... il che potrebbe introdurre una "caratteristica" da qualche altra parte più avanti lungo la linea. Utilizzando il metodo di configurazione, la maggior parte degli sviluppatori potrebbe non toccare nemmeno la logica principale (di solito).

Il problema è che al mio capo piace l'idea, ma vuole lasciare alcune costanti nei file di codice principale anche se sono usate una sola volta (cioè che il risultato 5 o max è usato una sola volta (proprio lì), così fa davvero avere senso riferirsi ad esso da un'altra classe / file?) Io, naturalmente, penso così a causa dei summenzionati motivi, oltre che è solo un codice più pulito e più coerente.

Il mio modo di pensare è più in linea con le convenzioni / metodologie di codifica corrette o è il mio capo?

Sto bene a farlo a modo suo, ma sembra che tornerà a tormentarmi più tardi lungo la strada.

methodology conventions

posta B1313 15.01.2017 - 18:50

fonte

2 risposte

Leggi altre domande sui tag methodology conventions

Perché abbiamo i metodi dei mutatori? I requisiti richiesti sono ancora parte del Product Backlog?

score 5 · Answer 1

Ci stai chiedendo di scegliere tra due mali non necessari.

Dai ai numeri nomi significativi. Un file di configurazione può farlo ma non è necessario. Le costanti locali, iniettabili o meno, possono dare loro anche i nomi. Non c'è una buona scusa per lasciare che i numeri magici scorrano nudi. Il contesto può rendere evidente il significato, ma il contesto può cambiare. Favorire la leggibilità.

Un unico file di configurazione per dominarli è un piano destinato a progetti tutt'altro che banali. Dare ad ogni file di configurazione un buon nome che chiarisca cosa fa e cosa non ci appartiene.

Non c'è alcun sostituto per il tempo dedicato a dare alle cose dei bei nomi.

score 4 · Answer 2

Una cosa da considerare è che introducendo una classe Config si introducono dipendenze aggiuntive nel codice. Molte, se non tutte le tue classi dipenderanno da questa classe Config . (Una classe di questo tipo è talvolta definita un magnete di dipendenza.) Anche una classe che usa solo una singola costante dalla classe Config ha fondamentalmente accesso a tutti loro. Questo è l'opposto dell'incapsulamento. A seconda dell'IDE, sarà anche difficile scoprire quale costante viene utilizzata da quali classi.

Per ridurre le dipendenze e migliorare l'incapsulamento, suggerisco quanto segue:

Se il valore costante specifico è essenziale per l'algoritmo e non ha senso modificarlo, basta usare il valore ovunque sia necessario e non definire nulla. Esempio: il calcolo di un prodotto incrociato funziona solo in 3 dimensioni. Quindi scrivi "3" ovunque sia necessario. Non dichiarare NumberOfDimensions=3 perché ciò darebbe l'impressione che questo valore possa essere modificato.
Se una costante viene utilizzata solo in una funzione o classe ed è improbabile che venga mai utilizzata da qualche altra parte, dichiararla localmente o come attributo di classe. Questo funziona anche per le gerarchie di classi se si inseriscono le costanti nella classe base.
Se viene utilizzato da più classi correlate (un modulo) che non hanno una classe base comune, dichiara una classe Config specifica del modulo.
Se la costante è davvero necessaria per quasi tutte le tue classi, inseriscila nella tua classe globale Config . Credo che questo sia un caso relativamente raro. Un esempio potrebbe essere un nome di file di registro e un livello di registro.