Esiste un limite sul numero di consensi globali utilizzati prima che un'applicazione venga considerata una programmazione errata?

Va bene interrompere le regole di programmazione se si comprendono i potenziali problemi che le regole sono progettate per evitare. Per le costanti globali, i problemi principali sono individuabilità, conflitti di nomi, test di unità di difficoltà e difficoltà a riconoscere una scarsa coesione. Prenderò seriamente in considerazione la possibilità di refactoring nelle seguenti circostanze:

• Sei costantemente alla ricerca di qualcosa che cerchi dove trovare una costante esistente o dove dovrebbe essere una nuova.
• Ti ritrovi a creare nomi come HOME1 , HOME2 , ecc. perché il nome che hai desiderato è già stato preso.
• L'esempio sta inducendo un collega meno esperto a utilizzare i globali dove non sono né utili né più leggibili.
• Desideri test di unità di scrittura che devono modificare tali costanti.
• Richieste di funzionalità o bug richiedono spesso la modifica di diversi file.

Per eliminarli, hai un paio di opzioni:

• Limita l'ambito di una costante a un singolo file anziché all'intera applicazione. Se questo è difficile da fare, probabilmente significa che il tuo codice non è sufficientemente coeso e ha bisogno di refactoring.

• Crea un oggetto o oggetti che passi alle funzioni che ne hanno bisogno. Questo richiede un po 'di pratica per definire una gerarchia che funzioni.

Avere molte costanti in un'applicazione non è un problema per sé stesso - averli tutti nello spazio dei nomi globale può diventare uno quando l'applicazione diventa più grande. Quindi, se hai 44 costanti, puoi considerare di raggrupparle in classi o spazi dei nomi.

Un'altra cosa da considerare è se è una buona idea avere tutte quelle costanti che fanno parte del tuo programma. La separazione di alcuni di essi in un file di configurazione consente di consegnare il mantenimento di questi valori a un'altra persona (ad esempio, un amministratore del cliente). In questo modo puoi distribuire più facilmente una nuova versione dell'applicazione al tuo cliente con un rischio minore che i valori personalizzati vengano accidentalmente sovrascritti.

In generale, le statistiche globali sono scoraggiate. Ma alcune cose sono davvero "globali" nel senso che un singolo valore o impostazione deve essere condivisa da molti pezzi di codice diversi. A volte, come sottolinea Karl, condividere i dati tra diverse aree della tua applicazione può significare che la tua applicazione è strutturata male. Se hai 26 file sorgente (denominati AZ per semplicità) e 10 globali e 5 di questi "globali" sono utilizzati solo dai file C, H e N, allora potresti voler guardare C, H e N per vedere cosa altrimenti hanno in comune e vedono se ha senso unire C, H e N e rendere privata la metà dei tuoi ex globals.

D'altra parte, alcune informazioni potrebbero essere veramente globali, come "nome-applicazione" o "modalità-tutto-app-in-speciale-test". Queste cose possono essere utilizzate nella maggior parte dei file dell'applicazione. Alcuni test per buoni globals sono:

• Il valore è immutabile una volta impostato (buono) o devi preoccuparti di una parte dell'applicazione che la modifica in fase di esecuzione e un'altra parte che ottiene il valore precedente per errore (errata)?

• È veramente globale - un singolo valore che deve essere utilizzato da diverse sezioni indipendenti della tua applicazione? Ovviamente vuoi eliminare le dipendenze non necessarie, ma alcune dipendenze sono necessarie.

• Non essere un idiota. Ho sentito storie di persone che rendono "attualmente loggato" un globale, limitando così l'applicazione web a un singolo utente loggato. Questo tipo di global è troppo stupido per essere chiamato male, ma succede.

Ad esempio, quando pronunci "nomi di sessione" che potrebbero significare due cose:

GOOD Global:
// Key used to look up number of items in individual user's shopping cart
// Each user's session has a hashtable of values and this is better than
// hard-coding the "numCartItems" string each time you use it because
// the compiler will catch a typo in the NUM_CART_ITEMS symbol, but not
// in a string:
String NUM_CART_ITEMS = "numCartItems";

BAD Global:
// Stores number of items in individual user's shopping cart
// but puts everyone's items in the same cart - OOPS!
int NUM_CART_ITEMS = 0;