Есть основной скрипт (index.php), в который включаются вспомогательные:
require_once('include/1.php');
require_once('include/2.php');
Больше в нём ничего нет, вся работа происходит во вспомогательных скриптах (1 и 2 в данном случае).
Предположим, в скрипте 1.php я объявляю и работаю с переменной:
$query = $db->query(....);
....
предположим, во втором скрипте (2.php) я объявляю ту же переменную для других целей
$query = $db->query(....);
....
но иногда случается ситуация, когда во втором скрипте переменная используется ДО её объявления в том же втором скрипте, например:
if ($aaa)
{
echo $query;
}
if ($click)
{
$query = $db->query(....);
}
....
В этом случае, естественно, она берётся из 1.php. Сразу прошу абстрагироваться от смысловой нагрузки кода, это просто утрированный пример.
Как исключить подобные ситуации? Как ограничить видимость переменных одним подключаемым файлом? Делать в конце каждого скрипта unset нудно, и можно пропустить что нибудь...
Или нужно писать как-то по другому?
Спустя 2 минуты, 38 секунд (10.07.2012 - 17:21) Invis1ble написал(а):
| Цитата |
| Или нужно писать как-то по другому? |
да, нужно по максимуму ограничивать область видимости
Спустя 2 минуты, 26 секунд (10.07.2012 - 17:23) Michael написал(а):
попробуй вообще обойтись по максимуму без глобальных переменных. Код разбей на функции, все что надо функции передавай в аргументах.
Спустя 16 часов, 26 минут, 11 секунд (11.07.2012 - 09:49) victoor написал(а):
Ну а вообще есть какие-то рекомендации? Иными словами "Как сейчас пишут" (с)? 
Спустя 1 час, 28 минут, 49 секунд (11.07.2012 - 11:18) interested написал(а):
victoor
Очень успешным и широко используемым в промышленных программных продуктах стало применение принципа "сокрытия сложности реализации сложностью структуры", поддерживаемое, главным образом, объектно-ориентированными инструментами. В той или иной степени их используют все.
Как бы там не сложилось, следует познакомиться с этим подходом обязательно.
В современных продуктах, скорее всего, подобные ситуации, как ваша, будут разрешаться: пространствами имён, фабриками объектов, локаторами ресурсов и т.д.
Что самое простое можно посоветовать?
i) Как правильно было замечено: избавляться от глобальных переменных. Использовать возможности "автоматической памяти". Скорее всего ваши сценарии представляют "модули". Каждый из них принимает какие-то входные данные и выполняет процедуры. Инкапсулируйте модули в вызовы функций:
A.php
B.php
Тогда каждая функция будет иметь отдельную автоматическую память и свою область видимости переменных. $query объявленное в одной функции "умрёт" после вызова и не будет мешать работе в другой функции, там будет новая, своя переменная
ii) Если возникает ситуация, которая повторяется и может быть выделена в отдельный алгоритм -- сделайте это! Делегируйте повторяющиеся действия функциям.
Это самое простое, что можно посоветовать. Буквально на уровне возможностей Fortran77.
Современный PHP располагает куда более замысловатыми способами усложнения структуры для сокрытия сложности алгоритма от клиента и разделения ответственности. Познакомьтесь с ними.
Очень успешным и широко используемым в промышленных программных продуктах стало применение принципа "сокрытия сложности реализации сложностью структуры", поддерживаемое, главным образом, объектно-ориентированными инструментами. В той или иной степени их используют все.
Как бы там не сложилось, следует познакомиться с этим подходом обязательно.
В современных продуктах, скорее всего, подобные ситуации, как ваша, будут разрешаться: пространствами имён, фабриками объектов, локаторами ресурсов и т.д.
Что самое простое можно посоветовать?
i) Как правильно было замечено: избавляться от глобальных переменных. Использовать возможности "автоматической памяти". Скорее всего ваши сценарии представляют "модули". Каждый из них принимает какие-то входные данные и выполняет процедуры. Инкапсулируйте модули в вызовы функций:
A.php
function someFuncA(...) { ... };
someFuncA($requestParameters);
B.php
function someFuncB(...) { ... };
someFuncB($requestParameters);
Тогда каждая функция будет иметь отдельную автоматическую память и свою область видимости переменных. $query объявленное в одной функции "умрёт" после вызова и не будет мешать работе в другой функции, там будет новая, своя переменная
ii) Если возникает ситуация, которая повторяется и может быть выделена в отдельный алгоритм -- сделайте это! Делегируйте повторяющиеся действия функциям.
Это самое простое, что можно посоветовать. Буквально на уровне возможностей Fortran77.
Современный PHP располагает куда более замысловатыми способами усложнения структуры для сокрытия сложности алгоритма от клиента и разделения ответственности. Познакомьтесь с ними.
Спустя 1 час, 46 минут, 54 секунды (11.07.2012 - 13:05) victoor написал(а):
Спасибо за развёрнутый ответ! Пока остановлюсь на функциях.
| Цитата |
| Современный PHP располагает куда более замысловатыми способами усложнения структуры для сокрытия сложности алгоритма от клиента и разделения ответственности. Познакомьтесь с ними. |
А эти способы как-то называются?
Спустя 2 часа, 3 минуты, 55 секунд (11.07.2012 - 15:09) interested написал(а):
victoor
| Цитата |
| А эти способы как-то называются? |
victoor
Конечно!
PHP поддерживает пространства имён / namespace , что позволяет создавать структуры данных с простыми названиями, без опасения конфликта.
PHP поддерживает основные элементы ООП: возможность описать целую алгебру и скрыть детали реализации. Classes / objects.
PHP поддерживает полиморфизм интерфейсов.
PHP поддерживает наследование, однако с присущим полиморфизмом контракта, как в Java.
PHP поддерживает принцип анонимных функций closure
PHP поддерживает специальные структуры для делегирования и разделения функциональности traits
И ещё специальные приёмы вроде "магических методов": __invoke -- позволяет своего рода "перегрузить скобки", __call -- вызвать неописанный в классе явно метод.
Это целый свой "зоопарк".
Это не значит, что всё это нужно обязательно использовать, вовсе нет.
Но желательно иметь представление о том, что это.
Возможно, в некий момент возникнет задача, где подобные способы сокрытия сложности в структуре помогут сделать более ясный и понятный код. Разделить его на независимые куски и снизить сложность сопровождения.
Конечно!
PHP поддерживает пространства имён / namespace , что позволяет создавать структуры данных с простыми названиями, без опасения конфликта.
PHP поддерживает основные элементы ООП: возможность описать целую алгебру и скрыть детали реализации. Classes / objects.
PHP поддерживает полиморфизм интерфейсов.
PHP поддерживает наследование, однако с присущим полиморфизмом контракта, как в Java.
PHP поддерживает принцип анонимных функций closure
PHP поддерживает специальные структуры для делегирования и разделения функциональности traits
И ещё специальные приёмы вроде "магических методов": __invoke -- позволяет своего рода "перегрузить скобки", __call -- вызвать неописанный в классе явно метод.
Это целый свой "зоопарк".
Это не значит, что всё это нужно обязательно использовать, вовсе нет.
Но желательно иметь представление о том, что это.
Возможно, в некий момент возникнет задача, где подобные способы сокрытия сложности в структуре помогут сделать более ясный и понятный код. Разделить его на независимые куски и снизить сложность сопровождения.
Спустя 21 минута, 51 секунда (11.07.2012 - 15:31) victoor написал(а):
Ещё раз спасибо, буду изучать потихоньку