Quando è ok usare una variabile globale

Per quanto ne so, un campo statico pubblico è fondamentalmente globale dato che può essere chiamato da qualsiasi luogo con l'eccezione che non ostruisce lo spazio dei nomi.

L'unica volta che uso personalmente variabili "globali" nel mio codice sono sotto forma di campi statici pubblici che sono immutabili. In questo caso non è necessario preoccuparsi del fatto che il valore sia aggirato da altre parti del programma e naturalmente è molto più bello che avere una dozzina di variabili con gli stessi valori permanenti in ogni classe.

Personalmente, uso le globali per la configurazione runtime - se una proprietà di configurazione viene caricata all'avvio dell'applicazione e cambia solo raramente (e solo allora da una posizione), è terribile e soggetta a errori a passare a ogni metodo che potrebbe bisogno di usarlo ad un certo punto. È meglio usare qualcosa che può essere portato in campo da qualsiasi luogo che debba utilizzarlo, in quanto ciò non ingombra e oscura le firme dei metodi e chiama i siti.

Escludendo i sistemi in tempo reale / incorporati, dovresti usare solo i globali per i valori costanti, davvero. Se ritieni di non poter risolvere il tuo problema senza di loro, probabilmente stai facendo qualcosa di sbagliato.

Guarda anche Singleton pattern , che fornisce una soluzione migliore per i globals in quelle situazioni in cui hai bisogno di qualcosa avere un punto di accesso globale.

Il problema con le variabili globali è che devi essere consapevole di loro ovunque nel tuo codice. Tuttavia, una volta che hai deciso che hai bisogno di sapere su un particolare globale, c'è ancora qualcosa di perso nell'usarlo pesantemente. Quindi la mia opinione è che dovresti avere pochissime variabili globali, ma le poche che hai, dovresti ottenere il massimo chilometraggio.

Per un altro esempio di qualcosa su cui mi sento in questo modo, guarda l'uso dei mixin in Ruby.

Si tratta di spazi dei nomi.

Immagina per un momento che tutti nel mondo abbiano lo stesso cognome. Che casino.

(In India, i Sikh hanno lo stesso cognome: Singh - Prendi uno sguardo)

Versione breve: quando rende più facile ragionare sul programma. In genere i casi sono un tipo di stato globale o una risorsa statica ampiamente utilizzata.

Versione lunga: Tom Hawtin ha detto "con un'azione spettrale a distanza" ... questo è esattamente il problema con i globals: devi sapere dove viene usato e come, oppure puoi ottenere qualcosa di veramente strano e difficile per rintracciare i bug. I locali non sono niente di più o di meno di una strategia per ridurre l'ambito di ciò che il programmatore deve capire per ragionare sul programma.

Un altro aspetto del problema con la conoscenza di dove sono utilizzati è che si può finire con duplicati globali - nel qual caso le cose possono diventare davvero strane come la maggior parte dei programmi ottiene e imposta var1 mentre in un paio di posti var2 è usato per contenere le stesse informazioni. In particolare quando più persone stanno lavorando sullo stesso codice. Gli IDE possono essere utili per trovare l'utilizzo riducendo il costo dei globals, ma non fanno nulla per i duplicati.

Più globalmente hai più difficile è tenere traccia di ciò che sta accadendo con loro. Dovrebbero essere pochi e distanti tra loro.

I due trucchi con globali e singleton sono testabilità e schierabilità.

Per i test, ho visto troppe cinture di test troppo complesse solo per far fronte a una vita pianificata e singleton mal pianificata. Assicurati che qualsiasi oggetto di questo tipo abbia regole di avvio e smontaggio chiare e semplici.

Per quanto riguarda la deployabilità, ci sono due casi da considerare. In primo luogo, come vivrà il tuo oggetto globale? È in una libreria statica o dinamica? Se quell'oggetto globale viene riutilizzato per un plugin, otterrai copie extra? In secondo luogo, cosa succede quando quell'oggetto globale viene inserito in un'applicazione parallela? E 'thread-safe?

Nel complesso, immagino che queste ragioni significano che globals e singleton vengono usati solo eccezionalmente.

Lo sviluppo di sistemi embedded critici di solito comporta l'uso di variabili globali.

Le dimensioni dello stack sono minuscole, tutto è assegnato in modo statico ( malloc() è vietato), le variabili globali sono nascoste dall'esterno della libreria a cui appartengono.

In un orribile codice VB6 che abusa dei globali come se non ci fosse un domani, sono colpevole di averne introdotto uno nuovo:

Global CsExt As New TheAppBeingRewrittenInCSharpWhileVb6CodeIsStillBeingMaintained

Penso che sia uno dei pochi casi d'uso validi per un oggetto globale.