function foo () {
global $var;
// rest of code
}
Nei miei piccoli progetti PHP di solito vado in modo procedurale. In genere ho una variabile che contiene la configurazione del sistema e quando devo accedere a questa variabile in una funzione, lo faccio global $var;.
Questa è una cattiva pratica?
Risposte:
Quando le persone parlano di variabili globali in altre lingue significa qualcosa di diverso da quello che fa in PHP. Questo perché le variabili non sono realmente globali in PHP. Lo scopo di un tipico programma PHP è una richiesta HTTP. Le variabili di sessione hanno effettivamente un ambito più ampio rispetto alle variabili "globali" di PHP perché in genere comprendono molte richieste HTTP.
Spesso (sempre?) Puoi chiamare funzioni membro in metodi preg_replace_callback()come questo:
preg_replace_callback('!pattern!', array($obj, 'method'), $str);
Vedi i callback per ulteriori informazioni.
Il punto è che gli oggetti sono stati imbullonati su PHP e in qualche modo portano a qualche imbarazzo.
Non preoccuparti eccessivamente dell'applicazione di standard o costrutti da linguaggi diversi a PHP. Un'altra trappola comune è cercare di trasformare PHP in un linguaggio OOP puro incollando modelli di oggetti sopra tutto.
Come ogni altra cosa, usa variabili "globali", codice procedurale, un particolare framework e OOP perché ha senso, risolve un problema, riduce la quantità di codice che devi scrivere o lo rende più manutenibile e più facile da capire, non perché pensi dovresti.
array ($obj, 'callbackMethod')nelle chiamate a preg_replace_callback()? (Lo so, sono caduto preda di questa trappola OOP ...)
Le variabili globali, se non utilizzate con attenzione, possono rendere i problemi più difficili da trovare. Supponiamo che tu richieda uno script php e ricevi un avviso che dice che stai cercando di accedere a un indice di un array che non esiste in qualche funzione.
Se l'array a cui stai tentando di accedere è locale rispetto alla funzione, controlla la funzione per vedere se hai commesso un errore lì. Potrebbe essere un problema con un input alla funzione in modo da controllare i punti in cui viene chiamata la funzione.
Ma se quell'array è globale, devi controllare tutti i posti in cui usi quella variabile globale, e non solo quello, devi capire in quale ordine si accede a quei riferimenti alla variabile globale.
Se hai una variabile globale in un pezzo di codice, è difficile isolare la funzionalità di quel codice. Perché dovresti isolare la funzionalità? Quindi puoi testarlo e riutilizzarlo altrove. Se si dispone di codice che non è necessario testare e non è necessario riutilizzarlo, è possibile utilizzare le variabili globali.
sono d'accordo con Cletus. aggiungerei due cose:
i migliori saluti, don
$DB = 'foo';
Chi può discutere contro l'esperienza, i diplomi universitari e l'ingegneria del software? Non me. Vorrei solo dire che nello sviluppo di applicazioni PHP a pagina singola orientate agli oggetti, mi diverto di più quando so di poter costruire l'intera cosa da zero senza preoccuparmi delle collisioni nello spazio dei nomi. Costruire da zero è qualcosa che molte persone non fanno più. Hanno un lavoro, una scadenza, un bonus o una reputazione di cui preoccuparsi. Questi tipi tendono a utilizzare così tanto codice precostruito con una posta in gioco alta, che non possono rischiare di utilizzare variabili globali.
Può essere un male usare le variabili globali, anche se vengono utilizzate solo nell'area globale di un programma, ma non dimentichiamoci di coloro che vogliono solo divertirsi e far funzionare qualcosa .
Se questo significa usare poche variabili (<10) nello spazio dei nomi globale, queste vengono utilizzate solo nell'area globale di un programma, così sia. Sì, sì, MVC, inserimento delle dipendenze, codice esterno, blah, blah, blah, blah. Ma, se hai contenuto il 99,99% del tuo codice in spazi dei nomi e classi, e il codice esterno è sandbox, il mondo non finirà (ripeto, il mondo non finirà) se usi una variabile globale.
In generale, non direi che l'uso di variabili globali è una cattiva pratica . Direi che l'utilizzo di variabili globali (flag e simili) al di fuori dell'area globale di un programma è fonte di guai e (a lungo andare) sconsiderato perché puoi perdere traccia dei loro stati piuttosto facilmente. Inoltre, direi che più impari, meno dipenderai dalle variabili globali perché avrai sperimentato la "gioia" di rintracciare i bug associati al loro utilizzo. Questo da solo ti incentiverà a trovare un altro modo per risolvere lo stesso problema. Per coincidenza, questo tende a spingere le persone PHP nella direzione di imparare a usare gli spazi dei nomi e le classi (membri statici, ecc ...).
Il campo dell'informatica è vasto. Se spaventiamo tutti dal fare qualcosa perché lo etichettiamo male , allora perdono il divertimento di capire veramente il ragionamento dietro l'etichetta.
Usa le variabili globali se devi, ma poi vedi se puoi risolvere il problema senza di esse. Collisioni, test e debug significano di più quando si comprende intimamente la vera natura del problema, non solo una descrizione del problema.
Ripubblicato dalla versione beta della documentazione SO terminata
Possiamo illustrare questo problema con il seguente pseudo-codice
function foo() {
global $bob;
$bob->doSomething();
}
La tua prima domanda qui è ovvia
Da dove
$bobviene?
Sei confuso? Buono. Hai appena imparato perché i globali creano confusione e sono considerati una cattiva pratica. Se questo fosse un programma reale, il tuo prossimo divertimento è rintracciare tutte le istanze $bobe sperare di trovare quello giusto (questo peggiora se $bobviene utilizzato ovunque). Peggio ancora, se qualcun altro va e definisce $bob(o hai dimenticato e riutilizzato quella variabile) il tuo codice può rompersi (nell'esempio di codice sopra, avere l'oggetto sbagliato, o nessun oggetto, causerebbe un errore fatale). Poiché praticamente tutti i programmi PHP fanno uso di codice come il include('file.php');tuo lavoro, mantenere un codice come questo diventa esponenzialmente più difficile con il numero di file aggiunti.
Come evitiamo i Globali?
Il modo migliore per evitare le globali è una filosofia chiamata Dependency Injection . Qui è dove passiamo gli strumenti di cui abbiamo bisogno nella funzione o nella classe.
function foo(\Bar $bob) {
$bob->doSomething();
}
Questo è molto più facile da capire e da mantenere. Non è possibile indovinare dove è $bobstato impostato perché il chiamante è responsabile di saperlo (ci sta trasmettendo ciò che dobbiamo sapere). Meglio ancora, possiamo usare dichiarazioni di tipo per limitare ciò che viene passato. Quindi sappiamo che $bobè un'istanza della Barclasse o un'istanza di un figlio di Bar, il che significa che sappiamo che possiamo usare i metodi di quella classe. In combinazione con un autoloader standard (disponibile da PHP 5.3), ora possiamo rintracciare dove Barè definito. PHP 7.0 o versioni successive include dichiarazioni di tipo espanso, dove puoi anche usare tipi scalari (come into string).
$bob = Bar::instance();quando ne hai bisogno.
Come:
global $my_global;
$my_global = 'Transport me between functions';
Equals $GLOBALS['my_global']
è una cattiva pratica (come Wordpress $pagenow) ... hmmm
Considera questo:
$my-global = 'Transport me between functions';
è un errore PHP Ma:
$GLOBALS['my-global'] = 'Transport me between functions';
NON è un errore, i trattini non entreranno in conflitto con le variabili dichiarate dall'utente "comuni", come $pagenow. E l'utilizzo di MAIUSCOLO indica un superglobale in uso, facile da individuare nel codice o da tracciare con la ricerca nei file
Uso i trattini, se sono pigro per costruire classi di tutto per una singola soluzione, come:
$GLOBALS['PREFIX-MY-GLOBAL'] = 'Transport me ... ';
Ma nei casi di un utilizzo più ampio, utilizzo ONE globals come array:
$GLOBALS['PREFIX-MY-GLOBAL']['context-something'] = 'Transport me ... ';
$GLOBALS['PREFIX-MY-GLOBAL']['context-something-else']['numbers'][] = 'Transport me ... ';
Quest'ultimo è per me una buona pratica su obiettivi o utilizzo "cola light", invece di ingombrare ogni volta con classi singleton per "cache" alcuni dati. Per favore, fai un commento se sbaglio o mi manca qualcosa di stupido qui ...