Где хранить глобальные переменные?

Question

[xexsus]

Где, с точки зрения грамотной архитектуры, хранить глобальные переменные?



Ради большей чёткости вопроса, опишу остальные условия задачи, хотя многие наверное по умолчанию бы их подразумевали. Остальные условия такие:

* ООП;

* в первую очередь, интересует специфика web-приложений построенных согласно MVC-архитектуре.



Пример кода на PHP:

class Registry<br>
{<br>
	private static $_data = array();<br><br>
	/**<br>
	 * Установить переменную<br>
	 * @return true/false<br>
	 */<br>
	public static function set($key, $value)<br>
	{<br>
		if(array_key_exists($key,self::$_data)){<br>
			return false;<br>
		}<br>
		self::$_data[$key] = $value;<br>
		return true;<br>
	}<br><br>
	/**<br>
	 * Получить переменную<br>
	 * @return value/null<br>
	 */<br>
	public static function get($key)<br>
	{<br>
		if( !array_key_exists($key, self::$_data) ){<br>
			return null;<br>
		}<br>
		return self::$_data[$key];<br>
	}<br><br>
	/**<br>
	 * Удалить переменную<br>
	 */<br>
	public static function delete($key)<br>
	{<br>
		unset(self::$_data[$key]);<br>
	}<br>
}

Будет ли такой вариант хорошим?

Может есть способ проще и изящней?

Может можно вовсе обойтись без глобальных переменных?

Прошу делиться опытом.

Answer 1

[tikhop]

«Может можно вовсе обойтись без глобальных переменных?» — этот вопрос надо задавать себе лично.

А так, у тебя есть главная модель, которая хранит какое либо свойство. В свою очередь каждая вьюха и главный контроллер имеют ссылку на данную модель, тем самым имеют и доступ к нужному свойству модели.

Comments

[xexsus]

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

[Анатолий]

А чем Ваш ответ отличается от решения которое привел автор? Класс Registry не будет «главной моделью»? А вообще в любом случае судя по тегам у Вас MVC и значит присутствует FrontController некий, или вообще что-то что запускает приложение, вот в него и встройте этот Registry.

[Вячеслав Плиско]

taliban, вот, вы правы, если использовать filter chain, то можно $input, $output, $error передовать между фильтрами инъекцией в конструктор безо всяких реестров и одиночек.

Answer 2

[Сергей Савостин]

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

Comments

[xexsus]

Экземпляры классов тоже переменные. Если они не вложены в другие экземпляры классов, то они находятся в глобальном пространстве имён. Можно конечно эти объекты искусственно спрятать в статик-классы/функции, но это будет лишь дым и зеркала не меняющие положения вещей.

Получается, какие-то экземпляры классов высшей абстракции всё равно будут в глобальном пространстве имён (

[Сергей Савостин]

А вот почему они в глобальном пространстве? Имхо должен быть самый верхний супер-объект, для веб скажем это Site, который в себе содержит все остальные экземпляры других классов. Если переменная описывает свойства сайта, то она как бы «глобальная», т.е. принадлежит классу Site. Т.е. в итоге/идеале должно получиться дерево с одним «корнем». А если у Вас получается несколько корней, то по идее они должны быть объединены во что-то. По опыту сразу после этого в корневой класс потянутся всякие заброшенные где-то переменные и методы…

[xexsus]

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

В чём смысл правила — не создавать глобальные переменные? Чтобы минимизировать количество связей между частями кода. Есть нераспутываемый комок связей, мы оборачиваем его в один класс, и наружу торчит одна переменная, но проблему это не решает. Сложность системы не снизилась, хотя формально правило соблюдено. В этом и сложность. Можно поэкспериментировать, но реально почувствовать верность или неверность выбранного подхода можно будет только хорошо поработав над проектом.

[Сергей Савостин]

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

А какую проблему это не решает? Комка связей? Здесь, мне кажется, нужно именно убирать переменные, прямо не относящиеся к этому (корневому) классу туда, где им место. Ну, например, нужно ввести константу — размер буфера для чтения из сокета. Она как-бы глобальная и «удобно» настраивать все «на самом верху», но по сути константа относится непосредственно к сокету и должна принадлежать именно классу сокета (static естественно). В этом моя основная мысль организации архитектуры классов. Таким образом все, казалось бы глобальные, переменные/константы/настройки разбредутся по своим классам и в корневом останется только то, что относится к «сайту».

[Анатолий]

Если сделать один класс «главным» а все типа в нем, то получится на самом деле «комок связей», простая должна быть архитекрура. Нет ничего плохого в глобальных переменных, главное не «срать» ими бездумно, будет у Вас 3-4 класса в глобальном пространстве, ничего плохого не будет, каждый будет выполнять свою роль и общаться через посредников неких, просто и удобно. Если же делать дерево с одним корнем, тогда надо изначально очень сильно и плодотворно задуматься над качественным внутренним апи, иначе потом есть шанс все переделывать заново из-за «неувязочек» а архитектуре, потому как заранее все предусмотреть трудно.

[Сергей Савостин]

Понятно, что у оптимизации есть предел и цена. Скриптик на 10 строк мутить в ООП вообще нет смысла. Если проект серьезный и сложный, то архитектура — самое главное. Остальное — дело кодеров.

Answer 3

[Владимир Чернышев]

А зачем собственно вам нужны глобальные переменные?

Answer 4

[oandrew]

Глобальные переменные не нужны. Если нужны экземпляры обьектов — используйте Singleton паттерн. А в других всех случаях вероятней всего просто неправильная архитектура.

Comments

[xexsus]

Это получится использование Singleton не по назначению, и всё равно это будет той же глобальной переменной. Неважно с глобальной переменной связаны многие куски системы, или с синглтонами, путаные связи тянущиеся через всю систему останутся…

[oandrew]

Ну если говорить именно о Web программировании, то такой подход будет нормальным. Или по вашему примеру рестр или синглтоны классов. Посмотрите фреймворки разные, ничего особо нового в этом вопросе не придумаешь.
Скажем так: каждый обьект должен быть или уже создан и где то хранится(оперативная память, сериализация и т.д.), или должен создаватся с помощью простого new или какой нибудь фабрики и т.д.

Вот только тут назревает вопрос а нужна ли нам такая глобальность? Возможно когда вы хотите сделать что то глобальным, на самом деле нужно расширить область видимости. Такого плана:
было в методе класса — переносим в класс
было только в классе — делаем в суперклассе
ну а если нам нужно что то на много классов — тогда уже реестр/синглтон.

[Владимир Чернышев]

>ну а если нам нужно что то на много классов

Тогда или делаем суперкласс, или DI :)

Answer 5

[Disturbed]

Dependency injection ?!

Comments

[xexsus]

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

[Владимир Чернышев]

Я обычно рисую диаграмму (просто на бумажке), где указываю связи между объектами, причём стараюсь, чтобы на глобальном уровне был только один экземпляр объекта (условно две строки в программе: $app = new MyApplication(); $app->run();) и больше никаких глобальных переменных. Когда связи начинают дублироваться, запутываться, особенно когда они идут снизу вверх (app наверху, внизу бд, файлы, сокеты и т. п.), значит я что-то делаю не так и надо или что-то (свойства, методы) переносить из одного класса в другой, или создавать новые классы.

[Disturbed]

MyApplication::getInstance()->run();? :)

[xexsus]

Изящно, но всё же маскировка глобальной переменной под синглтон, без устранения недостатков глобальной переменной. Если синглтон будет вызываться из всех частей кода без разбора, то ничем не будет отличаться от той же глобальной переменной… (

[Disturbed]

Естественно, но это инстанс приложения, о котором писал VolCh. И вызывать его товсюду не имеет смысла

Answer 6

[Chvanikoff]

А Вы можете привести пример, когда Вам действительно могут понадобиться глобальные, внутри приложения, переменные?

Comments

[xexsus]

$app = new MyApplication;
$app->setMode('mobile');
$app->work();

[xexsus]

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

[Chvanikoff]

Для этого стоит использовать класс, отвечающий за работу с конфигурацией приложения.

[xexsus]

Да, но он всё равно будет выступать в роли глобальное переменной. Как бы это и пытаюсь решить. Всегда ли любая глобальная переменная — зло?

[Chvanikoff]

Фраза «Глобальная переменная — зло!» подразумевает под собой тот момент, что ее использование не прозрачно для человека, который впервые смотрит на код.
Сравните 2 куска кода:

[Chvanikoff]

извиняюсь, случайно отправил.
Так вот:

function set_app_name($name)
{
    global $settings;
    $settings['app_name'] = $name;
}

и простейший конфиг-класс

class Config {
    private static $data = array();
    
    public static function set($key, $value)
    {
        self::$data[$key] = $value;
    }

    public static function get($key, $default = NULL)
    {
        return isset(self::$data[$key]) ? self::$data[$key] : $default;
    }
}

По сути, в первом примере понятно, что глобально мы храним переменную конфига, НО!
Во втором случае мы имеем общий класс конфигурации, это примерно как использование namespace'ов.
Также возможен и третий вариант — псевдоуход от глобальных переменных — это «контейнер» навроде приведенного выше Registry, в котором будет, допустим, храниться двумерный массив $data['config'][$some_key]

[xexsus]

Угу, согласен. Но всё же глобальные переменные плохи не только из-за своей «мутности» для нового человека, но и из-за возможности доступа к ним из любого места программы, тем самым образуя кучу нежелательных связей. Другими словами, мы не можем быть уверены, что если уберём/модифицируем глобальную переменную(разумеется с сохранение функциональности модифицируемого участка кода), то вся программа не рухнет, так как возможно что большая часть модулей на неё завязана.

P.S. Где так красиво раскрашивают код?

[Владимир Чернышев]

Для того, чтобы не рухнуло, в методе get конфига есть параметр default :) А вообще, по хорошему, конфиги для приложения должны, имхо, читаться из конфиг-файлов по требованию (возможно с кэшированием)

Код раскрашивают тэгом <source lang=«php»>echo 'test';</source>

[Chvanikoff]

Я привел простейшую реализацию. А если говорить о конфигах — я сам использую в работе фреймворк Kohana (3) и считаю его метод работы с конфигами просто великолепным. :)