Quelle est l'utilité du mot - clé global ?

Y a-t-il des raisons de préférer une méthode à une autre?

• Sécurité?
• Performance?
• Rien d'autre?

Méthode 1:

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

Méthode 2:

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

Quand est-il judicieux d'utiliser global?

Pour moi, cela semble dangereux ... mais c'est peut-être juste un manque de connaissances. Je suis intéressé par des raisons techniques documentées (par exemple avec exemple de code, lien vers la documentation ...).

Merci d'avance!

Prime

C'est une belle question générale sur le sujet, je (@Gordon) offre une prime pour obtenir des réponses supplémentaires. Que votre réponse soit en accord avec la mienne ou donne un point de vue différent n'a pas d'importance. Puisque le globalsujet revient de temps en temps, nous pourrions utiliser une bonne réponse «canonique» pour établir un lien.

Les globaux sont mauvais

Cela est vrai pour le globalmot - clé ainsi que pour tout ce qui va d'une portée locale à une portée globale (statique, singletons, registres, constantes). Vous ne souhaitez pas les utiliser. Un appel de fonction ne devrait pas dépendre de quoi que ce soit à l'extérieur, par exemple

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
}

Tout cela rendra votre code dépendant de l'extérieur. Cela signifie que vous devez connaître l'état global complet de votre application avant de pouvoir appeler l'un de ces éléments de manière fiable. La fonction ne peut exister sans cet environnement.

L'utilisation des superglobales n'est peut-être pas une faille évidente, mais si vous appelez votre code à partir d'une ligne de commande, vous n'avez pas $_GETou $_POST. Si votre code repose sur l'entrée de ceux-ci, vous vous limitez à un environnement Web. Abstenez simplement la demande dans un objet et utilisez-le à la place.

En cas de couplage de noms de classes codés en dur (statiques, constantes), votre fonction ne peut pas non plus exister sans que cette classe soit disponible. C'est moins un problème quand il s'agit de classes du même espace de noms, mais lorsque vous commencez à mélanger à partir de différents espaces de noms, vous créez un désordre enchevêtré.

La réutilisation est gravement entravée par tout ce qui précède. Il en va de même pour les tests unitaires .

En outre, vos signatures de fonction mentent lorsque vous vous associez à la portée globale

function fn()

est un menteur, car il prétend que je peux appeler cette fonction sans rien lui passer. Ce n'est que lorsque je regarde le corps fonctionnel que j'apprends que je dois mettre l'environnement dans un certain état.

Si votre fonction nécessite des arguments pour s'exécuter, rendez-les explicites et transmettez-les:

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

exprime clairement de la signature ce qu'il faut appeler. Il ne dépend pas de l'environnement d'être dans un état spécifique. Tu n'as pas à faire

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

C'est une question de tirer (mot clé global) vs pousser (arguments). Lorsque vous insérez / injectez des dépendances, la fonction ne dépend plus de l'extérieur. Lorsque vous le faites, fn(1)vous n'avez pas besoin d'avoir une variable contenant 1 quelque part à l'extérieur. Mais lorsque vous insérez global $onedans la fonction, vous vous associez à la portée globale et vous attendez à ce qu'elle ait une variable de celle définie quelque part. La fonction n'est alors plus indépendante.

Pire encore, lorsque vous modifiez les globaux à l'intérieur de votre fonction, votre code sera rapidement complètement incompréhensible, car vos fonctions ont des effets secondaires partout.

En l'absence d'un meilleur exemple, considérez

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

Et puis tu fais

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

Il n'y a aucun moyen de voir que $fooces trois lignes ont changé. Pourquoi appeler la même fonction avec les mêmes arguments tout d'un coup changerait sa sortie ou changerait une valeur dans l'état global? Une fonction doit faire X pour une entrée définie Y. Toujours.

Cela devient encore plus grave lors de l'utilisation de la POO, car la POO concerne l'encapsulation et en atteignant la portée globale, vous rompez l'encapsulation. Tous ces singletons et registres que vous voyez dans les frameworks sont des odeurs de code qui devraient être supprimées au profit de l'injection de dépendances. Découplez votre code.

Plus de ressources:

• http://c2.com/cgi/wiki?GlobalVariablesAreBad
• En quoi le test du modèle de registre ou du singleton est-il difficile en PHP?
• Défaut: Brittle Global State & Singletons
• static considéré comme nocif
• Pourquoi les singletons n'ont aucune utilité en PHP
• SOLID (conception orientée objet)

La seule grande raison contre globalest que cela signifie que la fonction dépend d'une autre portée. Cela deviendra très rapidement compliqué.

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

contre.

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

Exiger $str1et $str2être configuré dans la portée appelante pour que la fonction fonctionne signifie que vous introduisez des dépendances inutiles. Vous ne pouvez plus renommer ces variables dans cette étendue sans les renommer également dans la fonction, et par conséquent également dans toutes les autres étendues que vous utilisez. Cela se transforme rapidement en chaos lorsque vous essayez de garder une trace de vos noms de variables.

globalest un mauvais modèle, même pour inclure des éléments mondiaux tels que les $dbressources. Il aura viendra le jour où vous souhaitez renommer , $dbmais ne peut pas, parce que votre application tout dépend du nom.

Limiter et séparer la portée des variables est essentiel pour écrire toute application complexe à mi-chemin.

Les globaux sont inévitables.

C'est une vieille discussion, mais je voudrais quand même ajouter quelques réflexions car elles me manquent dans les réponses mentionnées ci-dessus. Ces réponses simplifient ce qu'est trop un global et présentent des solutions qui ne sont pas du tout des solutions au problème. Le problème est: quelle est la bonne façon de traiter une variable globale et l'utilisation du mot-clé global? Pour cela, nous devons d'abord examiner et décrire ce qu'est un global.

Jetez un œil à ce code de Zend - et comprenez bien que je ne suggère pas que Zend soit mal écrit:

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',
   );

Il y a beaucoup de dépendances invisibles ici. Ces constantes sont en fait des classes. Vous pouvez également voir require_once dans certaines pages de ce framework. Require_once est une dépendance globale, créant ainsi des dépendances externes. C'est inévitable pour un cadre. Comment pouvez-vous créer une classe comme DecoratorPluginManager sans beaucoup de code externe dont cela dépend? Il ne peut pas fonctionner sans beaucoup d'extras. En utilisant le framework Zend, avez-vous déjà changé l'implémentation d'une interface? Une interface est en fait un global.

Une autre application utilisée dans le monde est Drupal. Ils sont très préoccupés par une conception appropriée, mais comme tout grand framework, ils ont beaucoup de dépendances externes. Jetez un œil aux globaux sur cette page:

/**
 * @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();

Avez-vous déjà écrit une redirection vers la page de connexion? Cela change une valeur globale. (Et puis ne dites-vous pas «WTF», que je considère comme une bonne réaction à une mauvaise documentation de votre application.) Le problème avec les globaux n'est pas qu'ils soient globaux, vous en avez besoin pour avoir une application significative. Le problème est la complexité de l'application globale qui peut en faire un cauchemar à gérer. Les sessions sont globales, $ _POST est un global, DRUPAL_ROOT est un global, le includes / install.core.inc 'est un global non modifiable. Il y a un grand monde en dehors de toute fonction nécessaire pour que cette fonction fasse son travail.

La réponse de Gordon est incorrecte, car il surestime l'indépendance d'une fonction et appeler une fonction un menteur simplifie à l'extrême la situation. Les fonctions ne mentent pas et lorsque vous regardez son exemple, la fonction est mal conçue - son exemple est un bogue. (En passant, je suis d'accord avec cette conclusion qu'il faut découpler le code.) La réponse de deceze n'est pas vraiment une définition correcte de la situation. Les fonctions fonctionnent toujours dans un cadre plus large et son exemple est bien trop simpliste. Nous conviendrons tous avec lui que cette fonction est totalement inutile, car elle renvoie une constante. Cette fonction est de toute façon une mauvaise conception. Si vous voulez montrer que la pratique est mauvaise, veuillez fournir un exemple pertinent. Renommer les variables dans une application n'est pas un problème avec un bon IDE (ou un outil). La question concerne la portée de la variable, pas la différence de portée avec la fonction. Il y a un moment propice pour qu'une fonction joue son rôle dans le processus (c'est pourquoi elle est créée en premier lieu) et à ce moment-là, elle peut influencer le fonctionnement de l'application dans son ensemble, donc également travailler sur des variables globales . La réponse de xzyfer est une déclaration sans argumentation. Les globaux sont tout aussi présents dans une application si vous avez des fonctions procédurales ou une conception POO. Les deux façons suivantes de modifier la valeur d'un global sont essentiellement les mêmes: donc aussi travailler sur des variables globales. La réponse de xzyfer est une déclaration sans argumentation. Les globaux sont tout aussi présents dans une application si vous avez des fonctions procédurales ou une conception POO. Les deux façons suivantes de modifier la valeur d'un global sont essentiellement les mêmes: donc aussi travailler sur des variables globales. La réponse de xzyfer est une déclaration sans argumentation. Les globaux sont tout aussi présents dans une application si vous avez des fonctions procédurales ou une conception POO. Les deux façons suivantes de modifier la valeur d'un global sont essentiellement les mêmes:

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

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

Dans les deux cas, la valeur de $ z est modifiée dans une fonction spécifique. Dans les deux modes de programmation, vous pouvez apporter ces modifications à un tas d'autres endroits du code. Vous pourriez dire qu'en utilisant global, vous pouvez appeler $ z n'importe où et y changer. Oui, vous pouvez. Mais allez-vous? Et quand cela est fait dans des endroits inadaptés, ne devrait-il pas être appelé un bogue?

Bob Fanger commente xzyfer.

Quelqu'un devrait-il alors utiliser n'importe quoi et en particulier le mot clé «global»? Non, mais comme tout type de design, essayez d'analyser ce dont cela dépend et ce qui en dépend. Essayez de savoir quand cela change et comment cela change. La modification des valeurs globales ne devrait se produire qu'avec les variables qui peuvent changer à chaque demande / réponse. Autrement dit, uniquement aux variables qui appartiennent au flux fonctionnel d'un processus, pas à sa mise en œuvre technique. La redirection d'une URL vers la page de connexion appartient au flux fonctionnel d'un processus, la classe d'implémentation utilisée pour une interface vers l'implémentation technique. Vous pouvez modifier ces dernières au cours des différentes versions de l'application, mais ne devez pas les modifier à chaque demande / réponse.

Pour mieux comprendre quand c'est un problème de travailler avec des globals et le mot-clé global et quand je ne vais pas vous présenter la phrase suivante, qui vient de Wim de Bie lors de l'écriture sur les blogs: «Personal yes, private no». Lorsqu'une fonction change la valeur d'une variable globale pour son propre fonctionnement, j'appellerai cette utilisation privée d'une variable globale et d'un bogue. Mais lorsque le changement de la variable globale est fait pour le bon traitement de l'application dans son ensemble, comme la redirection de l'utilisateur vers la page de connexion, alors est-ce à mon avis peut-être un bon design, pas par définition mauvais et certainement pas un anti-motif.

Rétrospectivement aux réponses de Gordon, deceze et xzyfer: ils ont tous des «oui privés» (et des bugs) comme exemples. C'est pourquoi ils s'opposent à l'utilisation de globaux. Je ferais aussi. Cependant, ils ne sont pas accompagnés d'exemples de «oui personnel, non privé», comme je l'ai fait plusieurs fois dans cette réponse.

En termes simples, il y a rarement une raison globalet jamais une bonne raison dans le code PHP moderne à mon humble avis. Surtout si vous utilisez PHP 5. Et surtout si vous développez du code orienté objet.

Les globaux affectent négativement la maintenabilité, la lisibilité et la testabilité du code. De nombreuses utilisations de globalpeuvent et doivent être remplacées par l'injection de dépendances ou simplement en passant l'objet global en tant que paramètre.

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

N'hésitez pas à utiliser des mots clés globaux dans les fonctions de PHP. Surtout, ne prenez pas les gens qui prêchent / hurlent de façon extravagante à quel point les globaux sont «mauvais» et ainsi de suite.

Premièrement, parce que ce que vous utilisez dépend totalement de la situation et du problème, et il n'y a AUCUNE solution / façon de faire quoi que ce soit dans le codage. Laissant totalement de côté l'erreur d'adjectifs religieux indéfinissables, subjectifs comme «mal» dans l'équation.

Exemple concret:

Wordpress et son écosystème utilisent des mots-clés mondiaux dans leurs fonctions. Soyez le code OOP ou non OOP.

Et à partir de maintenant, Wordpress représente essentiellement 18,9% d'Internet et gère les énormes mégasites / applications d'innombrables géants allant de Reuters à Sony, en passant par NYT et CNN.

Et ça le fait bien.

L'utilisation de mots-clés globaux à l'intérieur des fonctions libère Wordpress de la surcharge MASSIVE qui se produirait étant donné son énorme écosystème. Imaginez que chaque fonction demandait / passait n'importe quelle variable nécessaire à partir d'un autre plugin, core et retournait. Ajouté avec les interdépendances des plugins, cela aboutirait à un cauchemar de variables, ou à un cauchemar de tableaux passés en tant que variables. Un enfer à suivre, un enfer à déboguer, un enfer à développer. Empreinte mémoire incroyablement massive en raison du gonflement du code et du ballonnement variable également. Plus difficile à écrire aussi.

Il peut y avoir des gens qui viennent critiquer Wordpress, son écosystème, leurs pratiques et ce qui se passe dans ces régions.

Inutile, car cet écosystème représente à peu près 20% de la quasi-totalité d'Internet. Apparemment, cela fonctionne, il fait son travail et plus encore. Ce qui signifie que c'est la même chose pour le mot-clé global.

Un autre bon exemple est le fondamentalisme «iframes are evil». Il y a dix ans, il était hérésie d'utiliser des iframes. Et il y avait des milliers de personnes prêchant contre eux sur Internet. Vient ensuite Facebook, puis les réseaux sociaux, maintenant les iframes sont partout, des boîtes `` similaires '' à l'authentification, et le tour est joué - tout le monde se tait. Il y a ceux qui ne se sont toujours pas tus - à tort ou à raison. Mais vous savez quoi, la vie continue malgré de telles opinions, et même ceux qui prêchaient contre les iframes il y a dix ans doivent maintenant les utiliser pour intégrer diverses applications sociales aux propres applications de leur organisation sans dire un mot.

......

Coder Fundamentalism est quelque chose de très, très mauvais. Un petit pourcentage parmi nous peut être honoré du travail confortable dans une entreprise monolithique solide qui a suffisamment d'influence pour supporter le changement constant de la technologie de l'information et les pressions qu'elle entraîne en ce qui concerne la concurrence, le temps, le budget et d'autres considérations, et peut donc pratiquer le fondamentalisme et le strict respect des «maux» ou «biens» perçus. Des positions confortables qui rappellent la vieillesse, même si les occupants sont jeunes.

Pour la majorité cependant, le monde informatique est un monde en constante évolution dans lequel ils doivent être ouverts d'esprit et pratiques. Il n'y a pas de place pour le fondamentalisme, laissez de côté les mots-clés scandaleux comme «mal» dans les tranchées de première ligne de la technologie de l'information.

Utilisez simplement ce qui a le meilleur sens pour le problème AT HAND, avec des considérations appropriées pour un avenir à court, moyen et long terme. N'ayez pas peur d'utiliser une fonctionnalité ou une approche, car elle a une animosité idéologique effrénée contre elle, parmi un sous-ensemble de codeurs donné.

Ils ne feront pas votre travail. Vous serez. Agissez selon votre situation.

Je pense que tout le monde a à peu près exposé les aspects négatifs des globaux. Je vais donc ajouter les points positifs ainsi que les instructions pour une bonne utilisation des globaux:

1. L'objectif principal des globals était de partager des informations entre les fonctions. à l'époque où il n'y avait rien de tel qu'une classe, le code php se composait d'un tas de fonctions. Parfois, vous auriez besoin de partager des informations entre les fonctions. En général, le global était utilisé pour ce faire avec le risque de corrompre les données en les rendant globales.

   Maintenant, avant qu'un certain happy go lucky simpleton commence un commentaire sur l'injection de dépendances, je voudrais vous demander comment l'utilisateur d'une fonction comme l'exemple get_post(1)connaîtrait toutes les dépendances de la fonction. Considérez également que les dépendances peuvent différer d'une
   version à l'autre et d'un serveur à l'autre. Le principal problème avec l'injection de dépendances est que les dépendances doivent être connues à l'avance. Dans une situation où cela n'est pas possible ou des variables globales indésirables étaient le seul moyen d'atteindre cet objectif.

   Grâce à la création de la classe, les fonctions courantes peuvent désormais être facilement regroupées dans une classe et partager des données. Grâce à des implémentations telles que les médiateurs, même des objets non liés peuvent partager des informations. Ce n'est plus necessaire.

2. Une autre utilisation des globaux est à des fins de configuration. Surtout au début d'un script avant le chargement des autochargeurs, les connexions à la base de données établies, etc.

   Lors du chargement des ressources, les globaux peuvent être utilisés pour configurer les données (c'est-à-dire quelle base de données utiliser où se trouvent les fichiers de bibliothèque, l'url du serveur, etc.). La meilleure façon de faire est d'utiliser la define()fonction car ces valeurs ne changent pas souvent et peuvent facilement être placées dans un fichier de configuration.

3. L'utilisation finale des globaux est de contenir des données communes (c'est-à-dire CRLF, IMAGE_DIR, IMAGE_DIR_URL), des indicateurs d'état lisibles par l'homme (c'est-à-dire ITERATOR_IS_RECURSIVE). Ici, les globaux sont utilisés pour stocker des informations destinées à être utilisées à l'échelle de l'application, leur permettant d'être modifiées et de faire apparaître ces modifications à l'échelle de l'application.

4. Le modèle singleton est devenu populaire en php pendant php4 lorsque chaque instance d'un objet occupait de la mémoire. Le singleton a aidé à sauver la RAM en n'autorisant qu'une seule instance d'un objet à être créée. Avant les références, même l'injection de dépendance aurait été une mauvaise idée.

   La nouvelle implémentation php des objets de PHP 5.4+ prend en charge la plupart de ces problèmes, vous pouvez passer des objets en toute sécurité avec peu ou pas de pénalité. Ce n'est plus necessaire.

   Une autre utilisation des singletons est l'instance spéciale où une seule instance d'un objet doit exister à la fois, cette instance peut exister avant / après l'exécution du script et cet objet est partagé entre différents scripts / serveurs / langages, etc. Ici, un modèle de singleton résout le problème. solution assez bien.

Donc, en conclusion, si vous êtes en position 1, 2 ou 3, alors utiliser un global serait raisonnable. Cependant, dans d'autres situations, la méthode 1 doit être utilisée.

N'hésitez pas à mettre à jour toutes les autres instances où les globaux doivent être utilisés.

Cela n'a aucun sens de créer une fonction concat en utilisant le mot clé global.

Il est utilisé pour accéder à des variables globales telles qu'un objet de base de données.

Exemple:

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

Il peut être utilisé comme une variation du modèle Singleton