Переменная определяет значение, но может быть ссылкой на другую переменную и иметь ее значение. В процессе исполнения алгоритма переменная обычно принимает множество различных значений. Константа хранит только одно значение. Объект непредсказуем: ему свойственно иметь структуру, содержание и множество особенностей.
Пространство имен – это совокупность переменных, констант, объектов, функций и иных конструкций, созданных разработчиком, на которые можно ссылаться через имя этого пространства имен.
Имена: сфера описания данных и алгоритмов
Имена элементов (переменных, констант, объектов, функций и других конструкций разработчика) никогда не пересекаются. Любое совпадение имен PHP интерпретирует как серьезную ошибку, а в случаях, когда он не может однозначно идентифицировать проблему, разработчик получает код, работающий не так, как было задумано, либо белое поле в браузере.
Все имена всех данных должны быть уникальны, поскольку пространство глобальное. Имена объектов и функций также не должны повторяться, но сфера глобальной видимости прерывается в телах методов объектов и функций. Здесь функционирует свое, локальное пространство имен и ничто не мешает именовать что-то внутри так же, как обозначено снаружи.
Приведенный пример – классика, если не обращать внимания на ключевое слово namespace: все, как всегда. Работает второй include. Префикс NameSpaceTwo\ перед именами функций уточняет, из какой вставки берется код.
Если из первой функции убрать ключевое слово global и операцию $iExt = 1; перенести на строчку выше, то про значение переменной 100 не будет знать ни первая функция, ни вторая.
Пространства имен: множество сфер описания
В показанном примере есть общий файл, который использует две вставки. В каждой вставке есть одна и та же функция scCheckName(). Какую из них выбрать, решает программист посредством имени того пространства, которое актуально в нужный момент времени в нужном месте кода.
Тот факт, что одно и то же имя присутствует в общем коде (после слияния вставок) не приводит к ошибке по той простой причине, что каждый файл вставки помечен своим собственным уникальным именем.
В первом файле все, что будет в нем описано, связывается с именем NameSpaceOne. Во втором файле все описания будут привязаны к имени NameSpaceTwo.
Допускается любое дублирование имен в обоих файлах, но в каждом из них любое имя элемента (переменной, константы, объекта, функции) должно быть уникальным.
В этом примере смена имени пространства имен в вызове функции scCheckName() избавила переменную $iExt второго пространства имен от изменения. Именно поэтому в примере специально выделено слово "изменена" – изменение на самом деле не состоялось. Значение переменной осталось прежним.
Тестирование и множественное проектирование
Эти простейшие примеры показывают: можно легко упростить разработку сложных проектов, повысить эффективность, производительность и ускорить работу. Однозначно, сразу появились первые идеи применения пространства имен:
- безопасное тестирование скриптов – путем замены "рабочих" пространств на тестовые аналоги;
- безопасное проектирование большими коллективами разработчиков – путем предоставления им "индивидуальных" пространств описания элементов.
На самом деле пространство имен имеет гораздо более важное значение. Язык PHP, пространство имен и каждый элемент описания (переменная, константа, объект...) уже очень давно предоставили разработчику возможность самостоятельно манипулировать синтаксисом и семантикой.
Конструкции языка и общее правило современного программирования: "понято" – исполнено – есть противоречие – "белый экран" на профессионального разработчика "не действует".
Многие программисты даже не в курсе, в каком месте искать сообщение PHP об ошибке, когда в браузере ничего нет (чистое белое поле). На определенном этапе своего развития программист мыслит синтаксисом и семантикой PHP, «работает» автоматом и результат: собственный синтаксис и собственная семантика в пределах дозволенного.
Белый экран – сразу однозначная реакция профессионального программиста и ошибка ликвидирована. Зачем тратить время на дебаггер и просмотр лога ошибок?
Объекты, массивы и пространства имен
Можно сказать, что переменные, константы и функции – это прошлый век, но они используются в разработке объектов. Хороший код – это когда алгоритм представлен взаимодействующими объектами, а не последовательностью корректных конструкций.
Если использовать массивы объектов, манипулировать идеей стека и последним (первым) элементом массива, то можно получить динамику: объекты сами "решают", как должен работать функционал сайта в зависимости от складывающейся ситуации.
На PHP пространство имен – это переменная особого рода, представленная собственным уникальным именем, часто сложно составленным. Имя пространства имен употребляется в коде. Если это строка, то можно одно пространство заменить на другое в ходе исполнения скрипта.
Если имена namespace PHP использует как значения переменных, то это еще более семантически нагруженный синтаксис, еще более сильный, чем массивы объектов.
Объект – это структура и содержание, которые характеризуются единством. Пространство имен – это множество объектов, элементов и связей между ними.
Нельзя проводить эксперименты на работающей системе, но благодаря namespace PHP предоставляет возможность моделировать реальную работающую систему в другом пространстве для целей:
- дальнейшего развития;
- тестирования;
- технического обслуживания и пр.
Если абстрагироваться от синтаксиса, предложенного разработчиками PHP, и представить пространства имен как глобальные сложные системы объектов, то горизонты возможностей расширяются многократно.
Синтаксис и применение пространства имен
Слово namespace PHP принимает только в первой строчке кода каждого файла. Все описания должны идти только за ним. Синтаксис включает в себя только имя, обозначенное в обычном понимании имени.
Существенно использовать правильные слова, отражающие смысл. Лучше, когда имя длинное, но в нем есть то, что дает четкое понимание, о каком пространстве идет речь, что оно делает, что описывает, что принимает или для чего создано.
Пространства могут быть вложены друг в друга до бесконечности, но этим не следует злоупотреблять. Имя должно быть понятным, вложенность – обоснована, а последовательность имен пространств должна иметь логику.
В применениях use и namespace, PHP допускает сложное кодирование, но всегда, когда есть такая возможность, лучше обойтись простым вариантом.
Общее правило: namespace – описание и это один файл, use – это импорт пространства в скрипт использования и назначение ему псевдонима (короткой ссылки).
Простой пример автозагрузки классов (объектов)
В задаче имеется объект для манипулирования строками, стилями оформления элементов страницы (описания CSS), объект даты, файловой системы и базы данных. Смысл реализации – создать по этим пяти позициям простые интерфейсы с целью использования нужных возможностей только через методы этих объектов.
Никакого прямого использования функций и конструкций языка не допускается. В такой задаче используется на PHP автозагрузка классов. Namespace рассматривается как совокупность объектов, находящихся в определенном месте файловой системы. Обычно, все объекты размещаются в файловой системе по смыслу, по папкам и в файлах с определенным названием.
В коде слева обозначено создание нужных пяти объектов, но где именно они находятся, не указано. В коде справа приведен текст автозагрузчика (основной скрипт), который при загрузке классов (объектов) автоматом подставляет нужный путь до места размещения объекта и расширение файла .php.
Пример множества пространств имен
Библиотека PhpOffice / PhpWord – качественный пример использования сложной иерархии множества пространств имен. Папка элементов содержит практически весь спектр элементов, доступных при формировании документа *.docx (MS Word), другие папки содержат необходимый инструментарий для работы с элементами, параграфами и таблицами.
Собственно, библиотека помещена в папку проекта по той причине, что пространство функциональности PhpOffice / PhpWord требовалось дополнить конкретным инструментарием и в конечном итоге создать собственный вариант аналогичного продукта.
Загрузка множества классов различных пространств имен
Использование PHP namespace autoload, когда необходимо загружать множества классов, а иерархия разработанной системы объектов достаточно сложна и представить ее сложно, приводит к необходимости создания жестких конструкций.
Ориентация разработчика (использующего продукт для продолжения работ) возможна только в контексте семантики (понимания проекта), которая представлена надлежащими сочетаниями слов, отражающих реальное значение и взаимосвязи объектов.
Необходимость применения библиотеки в индивидуальном проекте приводит к решению задачи, как сочетать пространства имен разработчика и авторов PhpOffice / PhpWord. Лучшим является размещение данного продукта (его пространств и объектов) в собственном пространстве проекта.
Существенно отметить, что без модификации пространств имен данного продукта на уровне его абстрактных элементов и загрузки классов обойтись не удастся. Это свидетельствует, что на PHP namespace использование внутренних пространств имен может быть выполнено недостаточно абстрактно и универсально.
Файловая система и локализация пространств
По существу, пространства имен – это «начертание» пути в файловой системе к нужному объекту. Использование имен файлов в качестве имен объектов – естественно и привычно. Использование имен папок в качестве именования пространств имен – объективно.
«Деревянная» организация информации достаточно громоздка в применении и усложняет разработку, но она является естественным представлением для систем объектов.
Проблема состоит в том, что этап разработки представлен определенным редактором кода, который сочетает в себе и видимое представление папок и содержание конкретной папки, но еще нет такого редактора, который бы обеспечивал сквозное движение по объектам и по папкам.
Проблема абстрактности и универсальности
Принято сознанием разработчика и объективно в действительности:
- объектно-ориентированное программирование (ООП) дает абстракцию и возможность манипулировать информацией согласно ее реальной семантике;
- пространства имен отражают положение скриптов, объектов и отчасти смысла проекта в файловой системе
Фактически, соединив абстракцию ООП на имена объектов (файлы) и наложив ее на файловую систему (папки) с адекватным формированием имен namepace (пути + имена), можно управлять формированием пространств имен в процессе исполнения скрипта.
Программирование уже приобрело мощную динамику развития, но, если перевести процесс и нагрузку этапа разработки с текстового редактора (в котором создаются скрипты и размещаются по деревьям папок) на идею формирования такого кода, который сам себя позволяет совершенствовать и размещать в нужном месте файловой системы – программирование поднимется на новую высоту.
*какой-то код*
}"? В этой статье про это ничего не говорится. Может, это одно и то же? Или же всё-таки есть различия между "namespace example\test;
*какой-то код*"
и тем, что я писал выше?
global code should be enclosed in global namespace declaration - "официальная" трактовка.
Естественно, что скобки при описании namespace отличаются от скобок в остальном коде.
Я бы не рекомендовал увлекаться возможностями пространства имен, всегда лучше использовать только МИНИМАЛЬНО НЕОБХОДИМЫЙ МИНИМУМ.
Успехов!