PHP globale nelle funzioni


100

Qual è l'utilità della parola chiave globale ?

Ci sono motivi per preferire un metodo a un altro?

  • Sicurezza?
  • Prestazione?
  • Qualunque altra cosa?

Metodo 1:

function exempleConcat($str1, $str2)
{
  return $str1.$str2;
}

Metodo 2:

function exempleConcat()
{
  global $str1, $str2;
  return $str1.$str2;
}

Quando ha senso usarlo global?

Per me sembra essere pericoloso ... ma potrebbe essere solo una mancanza di conoscenza. Sono interessato a ragioni tecniche documentate (ad es. Con esempio di codice, link alla documentazione ...).

Grazie in anticipo!


generosità

Questa è una bella domanda generale sull'argomento, io (@Gordon) offro una taglia per ottenere ulteriori risposte. Non importa se la tua risposta è in accordo con la mia o dà un punto di vista diverso. Dato che l' globalargomento viene fuori di tanto in tanto, potremmo usare una buona risposta "canonica" a cui collegarci.


2
dai un'occhiata a questo link: stackoverflow.com/questions/1557787 Ci sono molti articoli correlati in basso a destra di questa pagina
JohnP

Non è una risposta diretta alla tua domanda, ma per favore leggi questa vecchia domanda SO .
Ólafur Waage

1
Quindi, non posso leggere nessuna parola chiave pro-globale. 1) Perché è qui. 2) Perché le persone lo usano?
Pascal Qyy

@ G.Qyy Perché c'è goto? Perché le persone lo usano? Non lo usano (spero almeno): P
PeeHaa

Alla fine dello scorso anno (14 dicembre), qualcuno ha votato negativamente su questa domanda. Mi interessa molto sapere perché, perché tutti i punti di vista, compresi quelli negativi, sono interessanti. In questo caso più che mai! Sarò molto grato per qualsiasi indizio al riguardo.
Pascal Qyy

Risposte:


158

I globali sono cattivi

Questo è vero per la globalparola chiave così come per tutto il resto che va da un ambito locale a quello globale (statiche, singleton, registri, costanti). Non vuoi usarli. Una chiamata di funzione non dovrebbe fare affidamento su nulla al di fuori, ad es

function fn()
{
    global $foo;              // never ever use that
    $a = SOME_CONSTANT        // do not use that
    $b = Foo::SOME_CONSTANT;  // do not use that unless self::
    $c = $GLOBALS['foo'];     // incl. any other superglobal ($_GET, …)
    $d = Foo::bar();          // any static call, incl. Singletons and Registries
}

Tutto ciò farà sì che il tuo codice dipenda dall'esterno. Ciò significa che devi conoscere lo stato globale completo in cui si trova la tua applicazione prima di poter chiamare in modo affidabile uno di questi. La funzione non può esistere senza quell'ambiente.

L'uso delle superglobali potrebbe non essere un difetto ovvio, ma se chiami il tuo codice da una riga di comando, non hai $_GETo $_POST. Se il tuo codice si basa sull'input da questi, ti stai limitando a un ambiente web. Basta astrarre la richiesta in un oggetto e usarlo invece.

In caso di accoppiamento di nomi di classi hardcoded (statici, costanti), anche la funzione non può esistere senza che quella classe sia disponibile. Questo è meno un problema quando si tratta di classi dallo stesso spazio dei nomi, ma quando inizi a mixare da spazi dei nomi diversi, stai creando un pasticcio aggrovigliato.

Il riutilizzo è gravemente ostacolato da tutto quanto sopra. Così è il test unitario .

Inoltre, le firme delle funzioni mentono quando si accoppia all'ambito globale

function fn()

è un bugiardo, perché afferma che posso chiamare quella funzione senza passarle nulla. È solo quando guardo il corpo della funzione che imparo che devo impostare l'ambiente in un certo stato.

Se la tua funzione richiede che gli argomenti vengano eseguiti, rendili espliciti e passali:

function fn($arg1, $arg2)
{
    // do sth with $arguments
}

trasmette chiaramente dalla firma ciò che richiede per essere chiamato. Non dipende dall'ambiente essere in uno stato specifico. Non devi farlo

$arg1 = 'foo';
$arg2 = 'bar';
fn();

È una questione di inserire (parola chiave globale) e inserire (argomenti). Quando si inseriscono / iniettano dipendenze, la funzione non si basa più sull'esterno. Quando lo fai fn(1)non devi avere una variabile che contiene 1 da qualche parte all'esterno. Ma quando si inserisce globale $oneall'interno della funzione, ci si accoppia allo scope globale e ci si aspetta che abbia una variabile di quella definita da qualche parte. Allora la funzione non è più indipendente.

Ancora peggio, quando modifichi i valori globali all'interno della tua funzione, il tuo codice sarà rapidamente completamente incomprensibile, perché le tue funzioni hanno effetti collaterali dappertutto.

In mancanza di un esempio migliore, considera

function fn()
{
    global $foo;
    echo $foo;     // side effect: echo'ing
    $foo = 'bar';  // side effect: changing
}

E poi lo fai

$foo = 'foo';
fn(); // prints foo
fn(); // prints bar <-- WTF!!

Non c'è modo di vedere che è $foostato cambiato da queste tre righe. Perché chiamare la stessa funzione con gli stessi argomenti improvvisamente cambia il suo output o cambia un valore nello stato globale? Una funzione dovrebbe eseguire X per un input definito Y. Sempre.

Ciò diventa ancora più grave quando si utilizza OOP, perché OOP riguarda l'incapsulamento e raggiungendo l'ambito globale, si rompe l'incapsulamento. Tutti questi singleton e registri che vedi nei framework sono odori di codice che dovrebbero essere rimossi a favore di Dependency Injection. Disaccoppia il tuo codice.

Altre risorse:


10
Perché PHP implementa queste cose? C'è un'utilità? Sono sempre sorpreso dalle pericolose implementazioni in PHP che molte persone usano ogni volta ... È difficile per me credere che non ci siano ragioni logiche!
Pascal Qyy

5
Vorrei che tu potessi rendere i Globals più grandi del male .
Kermit

3
Wow, finalmente qualcuno ha spiegato bene perché i globali sono cattivi ... Ho sempre sentito che lo erano e ho visto alcuni esempi molto molto specifici sul perché, ma questa è davvero una spiegazione buona e completa per il motivo generale per cui. +1
Wingblade

Sono davvero in ritardo e capisco cosa stai dicendo, ma che ne dici delle connessioni mysqli? Dovrebbero essere passati ogni volta come parametro, o è un collegamento $ globale; consentito nei tuoi occhi?
Mave

2
Hai ragione, tranne che per le costanti. Non rappresentano uno "stato" dell'applicazione ed è consentito farvi riferimento dall'interno di una funzione. La funzione non "mente" se utilizza una costante dall'interno. Sono d'accordo che implica che il programmatore a un certo punto avesse una conoscenza dell'esterno, ma questo è un compromesso molto accettabile per ciò che è una costante. Inoltre, seriamente, non è un grosso problema.
Sebas

35

L'unico motivo principale globalè che significa che la funzione dipende da un altro ambito. Questo diventerà disordinato molto rapidamente.

$str1 = 'foo';
$str2 = 'bar';
$str3 = exampleConcat();

vs.

$str = exampleConcat('foo', 'bar');

Richiedere $str1e $str2impostare nell'ambito di chiamata affinché la funzione funzioni significa introdurre dipendenze non necessarie. Non è più possibile rinominare queste variabili in questo ambito senza rinominarle anche nella funzione e quindi anche in tutti gli altri ambiti in cui si sta utilizzando questa funzione. Questo presto si trasforma in caos mentre cerchi di tenere traccia dei nomi delle tue variabili.

globalè un cattivo schema anche per includere cose globali come le $dbrisorse. Ci sarà venuto il giorno in cui si desidera rinominare $db, ma non può, perché tutta l'applicazione dipende dal nome.

Limitare e separare l'ambito delle variabili è essenziale per scrivere qualsiasi applicazione complessa a metà.


1
Mi dispiace, ma perché dovrei assolutamente rinominare $db? È il DOP, diffuso ovunque. Perché dovrebbe essere modificato quando posso aggiornare separatamente le informazioni sulla connessione?
Casey Dwayne

3
@kcd Perché un giorno ti rendi conto di quanto sia grande l'iniezione di dipendenze e vuoi ristrutturare la tua app? Perché un giorno dovrai integrare le tue cose con altre cose che usano anche una $dbvariabile globale ? Perché un giorno scoprirai i test di unità e dovrai gestire più di una connessione al database alla volta per questo? Molte, molte ragioni.
inganno

35

I globali sono inevitabili.

È una vecchia discussione, ma vorrei comunque aggiungere alcuni pensieri perché mi mancano nelle risposte sopra menzionate. Quelle risposte semplificano ciò che un globale è troppo e presentano soluzioni che non sono affatto soluzioni al problema. Il problema è: qual è il modo corretto di trattare una variabile globale e l'uso della parola chiave global? Per questo dobbiamo prima esaminare e descrivere cos'è un globale.

Dai un'occhiata a questo codice di Zend e tieni presente che non suggerisco che Zend sia scritto male:

class DecoratorPluginManager extends AbstractPluginManager
{
/**
 * Default set of decorators
 *
 * @var array
 */
protected $invokableClasses = array(
    'htmlcloud' => 'Zend\Tag\Cloud\Decorator\HtmlCloud',
    'htmltag'   => 'Zend\Tag\Cloud\Decorator\HtmlTag',
    'tag'       => 'Zend\Tag\Cloud\Decorator\HtmlTag',
   );

Ci sono molte dipendenze invisibili qui. Quelle costanti sono in realtà classi. Puoi anche vedere require_once in alcune pagine di questo framework. Require_once è una dipendenza globale, quindi crea dipendenze esterne. Ciò è inevitabile per un framework. Come puoi creare una classe come DecoratorPluginManager senza molto codice esterno da cui dipende? Non può funzionare senza molti extra. Usando il framework Zend, hai mai cambiato l'implementazione di un'interfaccia? Un'interfaccia è infatti globale.

Un'altra applicazione utilizzata a livello globale è Drupal. Sono molto preoccupati per la corretta progettazione, ma proprio come ogni grande framework, hanno molte dipendenze esterne. Dai un'occhiata alle globali in questa pagina:

/**
 * @file
 * Initiates a browser-based installation of Drupal.
 */

/**
 * Root directory of Drupal installation.
 */
define('DRUPAL_ROOT', getcwd());

/**
 * Global flag to indicate that site is in installation mode.
 */
define('MAINTENANCE_MODE', 'install');

// Exit early if running an incompatible PHP version to avoid fatal errors.
if (version_compare(PHP_VERSION, '5.2.4') < 0) {
  print 'Your PHP installation is too old. Drupal requires at least PHP 5.2.4. See the     <a     href="http://drupal.org/requirements">system requirements</a> page for more     information.';
  exit;
}

// Start the installer.
require_once DRUPAL_ROOT . '/includes/install.core.inc';
install_drupal();

Hai mai scritto un reindirizzamento alla pagina di accesso? Questo sta cambiando un valore globale. (E poi non stai dicendo "WTF", che considero una buona reazione alla cattiva documentazione della tua applicazione.) Il problema con le globali non è che sono globali, ti servono per avere un'applicazione significativa. Il problema è la complessità dell'applicazione complessiva che può renderla un incubo da gestire. Le sessioni sono globali, $ _POST è globale, DRUPAL_ROOT è globale, include / install.core.inc 'è un globale non modificabile. C'è un grande mondo al di fuori di qualsiasi funzione richiesta per consentire a quella funzione di svolgere il suo lavoro.

La risposta di Gordon non è corretta, perché sopravvaluta l'indipendenza di una funzione e chiamare bugiardo una funzione semplifica eccessivamente la situazione. Le funzioni non mentono e quando dai un'occhiata al suo esempio la funzione è progettata in modo improprio - il suo esempio è un bug. (A proposito, sono d'accordo con questa conclusione che si dovrebbe disaccoppiare il codice.) La risposta di inganno non è davvero una definizione corretta della situazione. Le funzioni funzionano sempre in un ambito più ampio e il suo esempio è troppo semplicistico. Saremo tutti d'accordo con lui sul fatto che quella funzione è completamente inutile, perché restituisce una costante. Quella funzione è comunque un cattivo design. Se vuoi dimostrare che la pratica è cattiva, fornisci un esempio pertinente. Rinominare le variabili in un'applicazione non è un grosso problema avere un buon IDE (o uno strumento). La domanda riguarda l'ambito della variabile, non la differenza di ambito con la funzione. C'è un momento opportuno affinché una funzione svolga il suo ruolo nel processo (ecco perché viene creata in primo luogo) e in quel momento opportuno può influenzare il funzionamento dell'applicazione nel suo insieme, quindi lavorare anche su variabili globali . La risposta di xzyfer è un'affermazione senza argomentazioni. I globali sono altrettanto presenti in un'applicazione se si dispone di funzioni procedurali o progettazione OOP. I prossimi due modi per modificare il valore di un globale sono essenzialmente gli stessi: quindi lavorando anche su variabili globali. La risposta di xzyfer è un'affermazione senza argomentazioni. I globali sono altrettanto presenti in un'applicazione se si dispone di funzioni procedurali o progettazione OOP. I prossimi due modi per modificare il valore di un globale sono essenzialmente gli stessi: quindi lavorando anche su variabili globali. La risposta di xzyfer è un'affermazione senza argomentazioni. I globali sono altrettanto presenti in un'applicazione se si dispone di funzioni procedurali o progettazione OOP. I prossimi due modi per modificare il valore di un globale sono essenzialmente gli stessi:

function xzy($var){
 global $z;
 $z = $var;
}

function setZ($var){
 $this->z = $var;
}

In entrambi i casi il valore di $ z viene modificato all'interno di una funzione specifica. In entrambi i modi di programmazione puoi apportare queste modifiche in un mucchio di altri punti del codice. Potresti dire che usando global potresti chiamare $ z ovunque e cambiare lì. Si, puoi. Ma lo farai? E se fatto in luoghi inadeguati, non dovrebbe quindi essere chiamato un bug?

Bob Fanger commenta xzyfer.

Qualcuno dovrebbe quindi usare qualcosa e in particolare la parola chiave "globale"? No, ma proprio come qualsiasi tipo di design, prova ad analizzare da cosa dipende e cosa dipende da esso. Prova a scoprire quando cambia e come cambia. La modifica dei valori globali dovrebbe avvenire solo con quelle variabili che possono cambiare ad ogni richiesta / risposta. Cioè, solo a quelle variabili che appartengono al flusso funzionale di un processo, non alla sua implementazione tecnica. Il reindirizzamento di un URL alla pagina di login appartiene al flusso funzionale di un processo, la classe di implementazione utilizzata per un'interfaccia all'implementazione tecnica. Puoi cambiare quest'ultimo durante le diverse versioni dell'applicazione, ma non dovresti cambiarli ad ogni richiesta / risposta.

Per capire meglio quando è un problema lavorare con le globali e la parola chiave globale e quando no, introdurrò la frase successiva, che viene da Wim de Bie quando scrive sui blog: "Personale sì, privato no". Quando una funzione sta cambiando il valore di una variabile globale per il proprio funzionamento, chiamerò quell'uso privato di una variabile globale e un bug. Ma quando la modifica della variabile globale viene effettuata per la corretta elaborazione dell'applicazione nel suo insieme, come il reindirizzamento dell'utente alla pagina di login, allora è che a mio parere è possibile un buon design, non per definizione cattivo e certamente non un anti-modello.

In retrospettiva alle risposte di Gordon, ingannare e xzyfer: hanno tutti "sì privato" (e bug) come esempi. Questo è il motivo per cui sono contrari all'uso di globali. Lo farei anch'io. Tuttavia, non vengono forniti con esempi di "sì personale, no privato" come ho fatto più volte in questa risposta.


L'esempio di codice Drupal non utilizza le globali, utilizza le costanti. Una differenza molto importante è che una costante non può essere ridefinita una volta che è stata definita. Inoltre non puoi semplicemente confrontare le funzioni xyze setZ. Il primo cambia lo stato globale, il secondo è un metodo di classe e cambia solo lo stato dell'istanza su cui è stato chiamato.
Arjan

@ Arjen: se cerchi la parola chiave globale in Drupal 7.14, otterrai centinaia di risultati. È un vecchio problema con i public setter: non controlli il luogo in cui vengono modificati una volta che li hai resi pubblici. È stato consigliato di non utilizzarli affatto o di dichiararli privati, quindi non possono essere aggiunti in seguito.
Loek Bergman

@ Arjan: a causa del mio errore con l'ortografia del tuo nome non hai ricevuto alcuna notifica della mia risposta. Adesso lo farai. :-)
Loek Bergman

@LoekBergman: Ci sono circa 400 risultati per la parola globalin drupal 7.26 (che è l'ultima versione), alcuni di questi sono nei commenti e molti altri sembrano essere in codice che non è stato toccato per anni. Spero proprio che non useranno globals in drupal 8.
Arjan

@LoekBergman Per favore usa setter e getter. Non ci vuole molto tempo per la configurazione e consente ad altri che stanno usando il tuo codice e forse estendendo le tue classi di avere più controllo. Una volta reso pubblico un parametro, questo è tutto. non hai la possibilità di nasconderlo in seguito.
mAsT3RpEE

15

In poche parole, raramente c'è una ragione globale mai una buona nel moderno codice PHP IMHO. Soprattutto se stai usando PHP 5. E in più specialmente se stai sviluppando codice orientato agli oggetti.

I globali influenzano negativamente la manutenibilità, la leggibilità e la testabilità del codice. Molti usi di globalcan e dovrebbero essere sostituiti con Dependency Injection o semplicemente passando l'oggetto globale come parametro.

function getCustomer($db, $id) {
    $row = $db->fetchRow('SELECT * FROM customer WHERE id = '.$db->quote($id));
    return $row;
}

10

Non esitate a utilizzare parole chiave globali all'interno di functions in PHP. Soprattutto non accettare persone che predicano / urlano in modo stravagante come i globali siano "malvagi" e quant'altro.

In primo luogo, perché ciò che usi dipende totalmente dalla situazione e dal problema, e non esiste una soluzione / modo per fare qualcosa nella codifica. Lasciando completamente da parte l'errore di aggettivi indefinibili, soggettivi e religiosi come "male" nell'equazione.

Caso in questione:

Wordpress e il suo ecosistema utilizzano parole chiave globali nelle loro funzioni. Essere il codice OOP o non OOP.

E al momento Wordpress è fondamentalmente il 18,9% di Internet e gestisce gli enormi megasiti / app di innumerevoli giganti che vanno da Reuters a Sony, a NYT, alla CNN.

E lo fa bene.

L'utilizzo della parola chiave globale all'interno delle funzioni libera Wordpress da un enorme gonfiamento che sarebbe accaduto dato il suo enorme ecosistema. Immagina che ogni funzione chiedesse / passasse qualsiasi variabile necessaria da un altro plug-in, core e restituisse. Aggiunto con le interdipendenze dei plug-in, che finirebbe in un incubo di variabili o in un incubo di array passati come variabili. Un inferno da monitorare, un inferno da mettere a punto, un inferno da sviluppare. Impronta di memoria incredibilmente massiccia a causa del blocco del codice e anche del gonfiore variabile. Anche più difficile da scrivere.

Potrebbero esserci persone che si avvicinano e criticano Wordpress, il suo ecosistema, le loro pratiche e ciò che accade da quelle parti.

Inutile, poiché questo ecosistema è praticamente il 20% di quasi tutta Internet. Apparentemente, funziona, fa il suo lavoro e altro ancora. Il che significa che è lo stesso per la parola chiave globale.

Un altro buon esempio è il fondamentalismo "iframe sono il male". Un decennio fa era un'eresia usare iframe. E c'erano migliaia di persone che predicavano contro di loro su Internet. Poi arriva Facebook, poi i social, ora gli iframe sono ovunque, dalle caselle "mi piace" all'autenticazione, e voilà - tutti zitti. Ci sono quelli che ancora non hanno taciuto, a torto oa ragione. Ma sai una cosa, la vita va avanti nonostante tali opinioni, e anche quelli che predicavano contro gli iframe un decennio fa ora devono usarli per integrare varie app social nelle applicazioni della propria organizzazione senza dire una parola.

......

Il fondamentalismo dei codificatori è qualcosa di molto, molto brutto. Una piccola percentuale di noi può essere onorata del comodo lavoro in una solida azienda monolitica che ha abbastanza influenza per sopportare il costante cambiamento nella tecnologia dell'informazione e le pressioni che porta in relazione alla concorrenza, al tempo, al budget e ad altre considerazioni, e quindi può praticare fondamentalismo e stretta aderenza ai "mali" o ai "beni" percepiti. Posizioni comode che ricordano la vecchiaia queste sono, anche se gli occupanti sono giovani.

Per la maggior parte, tuttavia, il mondo IT è un mondo in continua evoluzione in cui devono essere aperti e pratici. Non c'è posto per il fondamentalismo, lasciate da parte parole chiave oltraggiose come "male" nelle trincee in prima linea della tecnologia dell'informazione.

Basta usare tutto ciò che ha più senso per il problema A PORTATA DI MANO, con considerazioni appropriate per il futuro a breve, medio e lungo termine. Non esitare a utilizzare qualsiasi caratteristica o approccio perché ha un'animosità ideologica dilagante contro di esso, tra qualsiasi sottoinsieme di programmatori.

Non faranno il tuo lavoro. Desideri. Agisci in base alle tue circostanze.


3
+1 per anti-fondamentalismo e così, ma dire semplicemente "molte persone lo usano / funziona / ecc." È solo un "argumentum ad populum", un sofisma di base. il fatto che la maggioranza delle persone pensi o faccia una cosa non prova che abbiano ragione! in mezzo alla folla, se appare un pericolo, la maggior parte delle persone farà cose stupide e alcune persone moriranno calpestate da altri. Hanno ragione a mettere un piede sul viso di questa bambina di cinque anni solo perché pensano di dover assolutamente spingere una porta che si apre solo se viene tirata per sfuggire al fuoco? Non credo proprio ...
Pascal Qyy

1
la maggioranza che fa qualcosa ovviamente non convalida nulla da sola. tuttavia, il caso è software. e se la maggioranza lo fa, e la maggior parte delle app e dei servizi creati da queste persone stanno tenendo bene (wordpress per molti altri), allora significa che possono essere utilizzati.
100

7

Penso che tutti abbiano più o meno esposto gli aspetti negativi dei globali. Quindi aggiungerò gli aspetti positivi e le istruzioni per un uso corretto delle globali:

  1. Lo scopo principale delle globali era condividere le informazioni tra le funzioni. quando non c'era niente come una classe, il codice php consisteva in un mucchio di funzioni. A volte è necessario condividere le informazioni tra le funzioni. In genere il global è stato utilizzato per eseguire questa operazione con il rischio di danneggiare i dati rendendoli globali.

    Ora, prima che qualche simpleton felice e fortunato inizi un commento sull'inserimento delle dipendenze, vorrei chiederti come l'utente di una funzione come example get_post(1)potrebbe conoscere tutte le dipendenze della funzione. Considera inoltre che le dipendenze possono differire da
    versione a versione e da server a server. Il problema principale con l'inserimento delle dipendenze è che le dipendenze devono essere conosciute in anticipo. In una situazione in cui ciò non è possibile o le variabili globali indesiderate erano l'unico modo per raggiungere questo obiettivo.

    Grazie alla creazione della classe, ora le funzioni comuni possono essere facilmente raggruppate in una classe e condividere i dati. Attraverso implementazioni come Mediators anche oggetti non correlati possono condividere informazioni. Non è più necessario.

  2. Un altro utilizzo per le globali è per scopi di configurazione. Principalmente all'inizio di uno script prima che i caricatori automatici siano stati caricati, le connessioni al database effettuate, ecc.

    Durante il caricamento delle risorse, le variabili globali possono essere utilizzate per configurare i dati (ovvero quale database utilizzare dove si trovano i file di libreria, l'url del server, ecc.). Il modo migliore per farlo è usare la define()funzione poiché questi valori non cambieranno spesso e possono essere facilmente inseriti in un file di configurazione.

  3. L'utilizzo finale delle variabili globali è di contenere dati comuni (ad esempio CRLF, IMAGE_DIR, IMAGE_DIR_URL), flag di stato leggibili dall'uomo (ad esempio ITERATOR_IS_RECURSIVE). Qui le globali vengono utilizzate per memorizzare le informazioni che devono essere utilizzate in tutta l'applicazione, consentendo loro di essere modificate e fare in modo che tali modifiche appaiano in tutta l'applicazione.

  4. Il pattern singleton è diventato popolare in php durante php4 quando ogni istanza di un oggetto occupava memoria. Il singleton ha aiutato a risparmiare ram consentendo la creazione di una sola istanza di un oggetto. Prima dei riferimenti anche l'iniezione di dipendenza sarebbe stata una cattiva idea.

    La nuova implementazione php di oggetti da PHP 5.4+ si prende cura della maggior parte di questi problemi, puoi tranquillamente passare gli oggetti in giro con poca o nessuna penalità. Non è più necessario.

    Un altro uso per i singleton è l'istanza speciale in cui deve esistere solo un'istanza di un oggetto alla volta, quell'istanza potrebbe esistere prima / dopo l'esecuzione dello script e quell'oggetto è condiviso tra diversi script / server / linguaggi ecc. Qui un pattern singleton risolve il problema soluzione abbastanza bene.

Quindi, in conclusione, se sei in posizione 1, 2 o 3, sarebbe ragionevole utilizzare un globale. Tuttavia in altre situazioni dovrebbe essere utilizzato il Metodo 1.

Sentiti libero di aggiornare qualsiasi altra istanza in cui dovrebbero essere utilizzate le globali.


6

Non ha senso creare una funzione concat utilizzando la parola chiave globale.

Viene utilizzato per accedere a variabili globali come un oggetto database.

Esempio:

function getCustomer($id) {
  global $db;
  $row = $db->fetchRow('SELECT * FROM customer WHERE id = '.$db->quote($id));
  return $row;
}

Può essere utilizzato come variazione del pattern Singleton


"non ha senso" - in realtà lo fa: un esempio implementerà una tabella di ricerca senza utilizzare OOP.
Nir Alfasi
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.