Какая польза от глобального ключевого слова ?

Есть ли причины предпочесть один метод другому?

• Безопасность?
• Производительность?
• Что-нибудь еще?

Способ 1:

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

Способ 2:

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

Когда есть смысл использовать global?

Для меня это кажется опасным ... но это может быть просто недостаток знаний. Меня интересуют задокументированные (например, с примером кода, ссылка на документацию ...) технические причины.

Заранее спасибо!

Щедрость

Это хороший общий вопрос по теме, я (@Gordon) предлагаю вознаграждение за дополнительные ответы. Согласуется ли ваш ответ с моим или дает другую точку зрения, не имеет значения. Поскольку эта globalтема возникает время от времени, мы могли бы использовать хороший «канонический» ответ для ссылки.

Глобалы злы

Это верно как для globalключевого слова, так и для всего остального, что простирается от локальной до глобальной (статика, синглтоны, реестры, константы). Вы не хотите их использовать. Вызов функции не должен полагаться ни на что извне, например

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
}

Все это заставит ваш код зависеть от внешнего мира. Это означает, что вы должны знать полное глобальное состояние, в котором находится ваше приложение, прежде чем вы сможете надежно вызвать любое из них. Функция не может существовать без этой среды.

Использование суперглобальных переменных может не быть очевидным недостатком, но если вы вызываете свой код из командной строки, у вас нет $_GETили $_POST. Если ваш код полагается на ввод от них, вы ограничиваетесь веб-средой. Просто абстрагируйте запрос до объекта и используйте его.

В случае связывания жестко запрограммированных имен классов (статических, констант) ваша функция также не может существовать без того, чтобы этот класс был доступен. Это меньшая проблема, когда это классы из одного и того же пространства имен, но когда вы начинаете микширование из разных пространств имен, вы создаете запутанный беспорядок.

Повторное использование серьезно затруднено из-за всего вышеперечисленного. Так что модульное тестирование .

Кроме того, ваши сигнатуры функций лгут, когда вы подключаетесь к глобальной области видимости

function fn()

является лжецом, потому что утверждает, что я могу вызвать эту функцию, ничего не передавая ей. Только когда я смотрю на тело функции, я узнаю, что мне нужно установить среду в определенное состояние.

Если вашей функции требуются аргументы для запуска, сделайте их явными и передайте:

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

из подписи ясно передает, что он требует называть. Пребывание в определенном состоянии не зависит от окружающей среды. Тебе не нужно делать

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

Это вопрос втягивания (глобальное ключевое слово) против нажатия (аргументов). Когда вы вставляете / вводите зависимости, функция больше не полагается на внешнее. Когда вы это сделаете, fn(1)вам не нужно иметь переменную, содержащую 1 где-то снаружи. Но когда вы втягиваете global $oneвнутри функции, вы присоединяетесь к глобальной области видимости и ожидаете, что где-то будет определена переменная этого типа. Тогда функция больше не является независимой.

Хуже того, когда вы меняете глобальные переменные внутри своей функции, ваш код быстро станет совершенно непонятным, потому что ваши функции повсюду имеют побочные эффекты.

Если не найти лучшего примера, рассмотрим

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

И тогда вы делаете

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

Невозможно увидеть, что $fooизменилось из этих трех строк. Почему вызов одной и той же функции с одними и теми же аргументами может внезапно изменить ее вывод или изменить значение в глобальном состоянии? Функция должна выполнять X для определенного входа Y. Всегда.

Это становится еще более серьезным при использовании ООП, потому что ООП касается инкапсуляции и, обращаясь к глобальной области видимости, вы нарушаете инкапсуляцию. Все эти синглтоны и реестры, которые вы видите во фреймворках, представляют собой запахи кода, которые следует удалить в пользу внедрения зависимостей. Отделите свой код.

Дополнительные ресурсы:

• http://c2.com/cgi/wiki?GlobalVariablesAreBad
• Как сложно тестировать шаблон реестра или синглтон в PHP?
• Недостаток: хрупкое глобальное состояние и одиночные игры.
• static считается вредным
• Почему синглтоны не используются в PHP
• SOLID (объектно-ориентированный дизайн)

Одна большая причина против globalзаключается в том, что это означает, что функция зависит от другой области. Это очень быстро испортится.

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

vs.

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

Требование $str1и $str2настройка в области вызова для работы функции означает, что вы вводите ненужные зависимости. Вы больше не можете переименовывать эти переменные в этой области, не переименовывая их также и в самой функции, а значит, и во всех других областях, в которых вы используете эту функцию. Вскоре это превращается в хаос, когда вы пытаетесь отслеживать имена переменных.

globalплохой шаблон даже для включения глобальных вещей, таких как $dbресурсы. Там будет наступит день , когда вы хотите переименовать , $dbно не может, потому что все ваше приложение зависит от имени.

Ограничение и разделение области переменных необходимо для написания любого полусложного приложения.

Глобалы неизбежны.

Это старое обсуждение, но я все же хотел бы добавить некоторые мысли, потому что мне их не хватает в вышеупомянутых ответах. Эти ответы упрощают то, что такое глобальное, и представляют решения, которые вовсе не являются решениями проблемы. Проблема в том, как правильно работать с глобальной переменной и использовать ключевое слово global? Для этого мы сначала должны изучить и описать, что такое глобальный.

Взгляните на этот код Zend - и, пожалуйста, поймите, что я не считаю, что Zend написан плохо:

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

Здесь много невидимых зависимостей. Эти константы на самом деле являются классами. Вы также можете увидеть require_once на некоторых страницах этого фреймворка. Require_once - это глобальная зависимость, следовательно, создаются внешние зависимости. Это неизбежно для фреймворка. Как можно создать такой класс, как DecoratorPluginManager, без большого количества внешнего кода, от которого он зависит? Он не может функционировать без множества дополнений. Вы когда-нибудь меняли реализацию интерфейса, используя Zend framework? Интерфейс на самом деле глобальный.

Еще одно глобально используемое приложение - Drupal. Они очень озабочены правильным дизайном, но, как и любой большой фреймворк, у них много внешних зависимостей. Взгляните на глобальные переменные на этой странице:

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

Вы когда-нибудь писали перенаправление на страницу входа? Это меняет глобальную ценность. (И тогда вы не говорите «WTF», что я считаю хорошей реакцией на плохую документацию вашего приложения.) Проблема с глобальными переменными не в том, что они глобальные, они нужны вам для того, чтобы иметь значимое приложение. Проблема заключается в сложности приложения в целом, с которым может быть просто кошмарно работать. Сеансы являются глобальными, $ _POST - глобальными, DRUPAL_ROOT - глобальными, include / install.core.inc '- неизменяемыми глобальными. За пределами любой функции существует большой мир, который требуется для того, чтобы эта функция выполняла свою работу.

Ответ Гордона неверен, потому что он переоценивает независимость функции и называя функцию лжецом, упрощает ситуацию. Функции не лгут, и когда вы посмотрите на его пример, функция спроектирована неправильно - его пример - ошибка. (Между прочим, я согласен с выводом о том, что код следует разделять.) Ответ обмана - это не совсем правильное определение ситуации. Функции всегда работают в более широком объеме, и его пример слишком упрощен. Мы все согласимся с ним в том, что эта функция совершенно бесполезна, потому что она возвращает константу. В любом случае эта функция - плохой дизайн. Если вы хотите показать, что практика плохая, приведите соответствующий пример. Переименование переменных в приложении - не проблема, если у вас есть хорошая IDE (или инструмент). Вопрос в области видимости переменной, а не в ее разнице с функцией. Существует подходящее время для того, чтобы функция выполняла свою роль в процессе (именно поэтому она создается в первую очередь), и в этот надлежащий момент она может влиять на функционирование приложения в целом, а значит, также работать с глобальными переменными. . Ответ xzyfer - утверждение без аргументов. Глобальные объекты также присутствуют в приложении, если у вас есть процедурные функции или дизайн ООП. Следующие два способа изменить значение глобального по существу одинаковы: следовательно, мы также работаем с глобальными переменными. Ответ xzyfer - утверждение без аргументов. Глобальные объекты также присутствуют в приложении, если у вас есть процедурные функции или дизайн ООП. Следующие два способа изменить значение глобального по существу одинаковы: следовательно, мы также работаем с глобальными переменными. Ответ xzyfer - утверждение без аргументов. Глобальные объекты также присутствуют в приложении, если у вас есть процедурные функции или дизайн ООП. Следующие два способа изменить значение глобального по существу одинаковы:

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

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

В обоих случаях значение $ z изменяется в рамках определенной функции. При обоих способах программирования вы можете вносить эти изменения в кучу других мест кода. Можно сказать, что с помощью global вы можете вызвать $ z где угодно и изменить там. Да, ты можешь. Но ты будешь? И если это сделано в неподходящих местах, не следует ли тогда называть это ошибкой?

Боб Фангер комментирует xzyfer.

Должен ли кто-нибудь тогда просто использовать что-нибудь, особенно ключевое слово «глобальный»? Нет, но, как и любой другой дизайн, постарайтесь проанализировать, от чего он зависит, а что от него. Постарайтесь узнать, когда оно меняется и как меняется. Изменение глобальных значений должно происходить только с теми переменными, которые могут изменяться при каждом запросе / ответе. То есть только к тем переменным, которые относятся к функциональному потоку процесса, а не к его технической реализации. Перенаправление URL-адреса на страницу входа принадлежит функциональному потоку процесса, классу реализации, используемому для интерфейса к технической реализации. Вы можете изменить последнее в разных версиях приложения, но не должны изменять их при каждом запросе / ответе.

Чтобы лучше понять, когда возникает проблема при работе с глобальными объектами и ключевым словом global, а когда нет, я представлю следующее предложение, которое исходит от Вима де Би, когда он пишет о блогах: «Личное да, личное нет». Когда функция изменяет значение глобальной переменной ради собственного функционирования, я буду называть это частное использование глобальной переменной и ошибкой. Но когда изменение глобальной переменной выполняется для правильной обработки приложения в целом, например, перенаправление пользователя на страницу входа в систему, то, на мой взгляд, возможно, хороший дизайн, а не по определению плохой и, конечно, не антипаттерн.

Оглядываясь назад на ответы Gordon, deceze и xzyfer: у всех них в качестве примеров есть «личное да» (и ошибки). Вот почему они против использования глобальных переменных. Я бы тоже. Однако в них нет примеров типа «личное да, частное нет», как я уже несколько раз делал в этом ответе.

Проще говоря, globalв современном PHP-коде редко есть причина и никогда не бывает хорошей. ИМХО. Особенно, если вы используете PHP 5. И особенно, если вы разрабатываете объектно-ориентированный код.

Глобалы негативно влияют на ремонтопригодность, читаемость и тестируемость кода. Многие варианты использования globalмогут и должны быть заменены внедрением зависимостей или простой передачей глобального объекта в качестве параметра.

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

Не бойтесь использовать глобальное ключевое слово внутри функций в PHP. Особенно не берите людей, которые диковинно проповедуют / кричат, что глобалы «злы» и тому подобное.

Во-первых, потому что то, что вы используете, полностью зависит от ситуации и проблемы, и НЕТ одного решения / способа что-либо сделать в кодировании. Полностью оставив в стороне ошибочность неопределенных, субъективных, религиозных прилагательных, таких как «зло», в уравнение.

Дело в точке :

Wordpress и его экосистема используют в своих функциях ключевое слово global. Будь то код ООП или не ООП.

И на данный момент Wordpress составляет в основном 18,9% Интернета, и на нем работают огромные мегасайты / приложения бесчисленных гигантов, от Reuters до Sony, от NYT до CNN.

И у него это хорошо получается.

Использование глобального ключевого слова внутри функций освобождает Wordpress от МАССОВОГО раздувания, которое могло бы произойти с учетом его огромной экосистемы. Представьте, что каждая функция запрашивает / передает любую переменную, которая требуется от другого плагина, ядра и возвращает. Добавлены взаимозависимости плагинов, которые закончились бы кошмаром переменных или кошмаром массивов, передаваемых как переменные. Ад за отслеживанием, ад за отладку, ад за разработку. Безумно большой объем памяти из-за раздувания кода и переменных. Писать тоже сложнее.

Могут быть люди, которые придумывают и критикуют Wordpress, его экосистему, их методы и то, что происходит в этих частях.

Бессмысленно, поскольку эта экосистема составляет примерно 20% всего интернета. Судя по всему, он ДЕЙСТВИТЕЛЬНО работает, он выполняет свою работу и многое другое. Это означает то же самое для глобального ключевого слова.

Еще один хороший пример - фундаментализм «iframe - зло». Десять лет назад использование iframe было ересью. И тысячи людей проповедовали против них в Интернете. Затем идет facebook, затем идут социальные сети, теперь iframe повсюду, от ящиков с отметками «Нравится» до аутентификации, и вуаля - все заткнулись. Есть те, кто до сих пор не заткнулся - справедливо или несправедливо. Но знаете что, жизнь продолжается, несмотря на такие мнения, и даже те, кто выступал против iframe десять лет назад, теперь вынуждены использовать их для интеграции различных социальных приложений в собственные приложения своей организации, не говоря ни слова.

......

Кодер-фундаментализм - это очень и очень плохо. Небольшой процент из нас может быть удостоен удобной работы в солидной монолитной компании, которая имеет достаточно влияния, чтобы выдерживать постоянные изменения в информационных технологиях и давление, которое они вызывают в отношении конкуренции, времени, бюджета и других соображений, и поэтому может практиковать фундаментализм и строгая приверженность воспринимаемому «злу» или «добру». Это удобные позы, напоминающие старину, даже если оккупанты молодые.

Однако для большинства ИТ-мир - это постоянно меняющийся мир, в котором им необходимо быть открытыми и практичными. Здесь нет места фундаментализму, оставим в стороне возмутительные ключевые слова, такие как «зло» в передовых окопах информационных технологий.

Просто используйте то, что лучше всего подходит для решения проблемы, СЕЙЧАС, с соответствующими соображениями на ближайшее, среднесрочное и долгосрочное будущее. Не уклоняйтесь от использования какой-либо функции или подхода, потому что они имеют безудержную идеологическую враждебность по отношению к любому данному подмножеству кодеров.

Они не сделают твою работу. Ты будешь. Действуйте в соответствии с вашими обстоятельствами.

Я думаю, что все в значительной степени разъяснили отрицательные аспекты глобалов. Поэтому я добавлю плюсы, а также инструкции по правильному использованию глобальных переменных:

1. Основная цель глобальных объектов заключалась в обмене информацией между функциями. когда еще не было ничего подобного классу, код php состоял из набора функций. Иногда вам может потребоваться обмен информацией между функциями. Обычно для этого использовалось глобальное значение, чтобы не повредить данные, сделав их глобальными.

   Теперь, прежде чем какой-нибудь счастливый, удачливый простак начнет комментировать инъекцию зависимостей, я хотел бы спросить вас, как пользователь функции, такой как пример, get_post(1)может знать все зависимости функции. Также учтите, что зависимости могут отличаться от
   версии к версии и от сервера к серверу. Основная проблема с внедрением зависимостей заключается в том, что зависимости необходимо знать заранее. В ситуации, когда это невозможно или нежелательные глобальные переменные были единственным способом достичь этой цели.

   Благодаря созданию класса, теперь общие функции можно легко сгруппировать в класс и обмениваться данными. Через такие реализации, как Mediators, даже несвязанные объекты могут обмениваться информацией. В этом больше нет необходимости.

2. Другое использование глобальных переменных - это конфигурация. Чаще всего в начале сценария до того, как будут загружены автозагрузчики, установлены соединения с базой данных и т. Д.

   Во время загрузки ресурсов глобальные переменные могут использоваться для настройки данных (т.е. какую базу данных использовать, где находятся файлы библиотеки, URL-адрес сервера и т. Д.). Лучший способ сделать это - использовать define()функцию, поскольку эти значения не будут часто меняться и могут быть легко помещены в файл конфигурации.

3. Конечное использование глобальных переменных - это хранение общих данных (например, CRLF, IMAGE_DIR, IMAGE_DIR_URL), удобочитаемых флагов состояния (например, ITERATOR_IS_RECURSIVE). Здесь глобальные переменные используются для хранения информации, предназначенной для использования в масштабе всего приложения, что позволяет изменять их и вносить изменения в приложение.

4. Шаблон singleton стал популярным в php во время работы php4, когда каждый экземпляр объекта занимал память. Синглтон помог сэкономить оперативную память, позволив создать только один экземпляр объекта. До появления ссылок даже внедрение зависимости было бы плохой идеей.

   Новая реализация объектов на PHP из PHP 5.4+ решает большинство этих проблем, вы можете безопасно передавать объекты с минимальными штрафами или без них. В этом больше нет необходимости.

   Еще одно использование синглтонов - это особый экземпляр, в котором одновременно должен существовать только один экземпляр объекта, этот экземпляр может существовать до / после выполнения скрипта, и этот объект используется совместно разными скриптами / серверами / языками и т. Д. Здесь одноэлементный шаблон решает решение довольно хорошо.

Итак, в заключение, если вы находитесь в позиции 1, 2 или 3, тогда использование global было бы разумным. Однако в других ситуациях следует использовать Метод 1.

Не стесняйтесь обновлять любые другие экземпляры, в которых следует использовать глобальные переменные.

Нет смысла создавать функцию concat с использованием ключевого слова global.

Он используется для доступа к глобальным переменным, таким как объект базы данных.

Пример:

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

Его можно использовать как вариацию паттерна Синглтон.