PHP NameSpace — как же все-таки его готовить? Пространства имен в PHP, разъяснение Тестирование и множественное проектирование

PHP, начиная с версии 5.3, подарил нам пространство имен. С тех пор идет где-то вялое, а где-то бурное обсуждение, как же это пространство имен использовать?
Некоторые фреймворки, такие как Symphony, Laravel, и, конечно же Zend взяли эту технологию на вооружение.
Все это более или менее вписалось в схему MVC. Осталась одна, наверное вечная, дискуссия, какой же должна быть главная брачная пара приложения - Модель и Контроллер?
Одни нам говорят, что Модель должна быть дородной и толстой и при ней стройный и тонкий Контроллер. Одним словом - матриархат.
Другие, наоборот, считают, что Контроллер должен всем управлять и повелевать, поэтому он получается основательный, упитанный. И при нем худенькая, стройненькая Модель, задача которой сводится к подай-принеси. Такой вот патриархат.
Так что же лучше в схеме MVC? Патриархат или матриархат?
Давайте посмотрим на это с точки зрения построения семейной ячейки на основе демократии. И пусть Namespace нам в этом поможет.

Нам не нравятся толстые, неуклюжие Контроллеры, которые, как слон в посудной лавке, по неосторожности могут раздавить все приложение.
Нам не нравятся также толстые Модели. Ну а кому они нравятся? Они должны быть достойны подиума!
Давайте попробуем с помощью Namespace, как с хорошей сватьей, создать гармоничную семью.

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

Мы создали основну структуру, где:

• Blog - это хранилище нашего приложения;
• Views и Templates - хранилище представлений и шаблонов;
• Utility - хранилище общих библиотек;
• index.php - bootstrap скрипт;
• Post - вот здесь и должна состояться семейная идиллия Контроллера и Модели.

С index.php все просто:

run(); /* * end of index.php */

Определяем нужные пути и создаем автозагрузчик.
Автозагрузчик загружает необходимые классы, которые расположены в иерархии папок согласно пространству имен класса. Например, класс BlogPostServicesView будет разыскиваться в Blog/Post/Services.
А вот и первая встреча с Namespace.
При старте index.php мы создаем экземпляр приложения Blog, класс которого загружается из Blog/Blog.php.
Посмотрим на него.

post = new Post(); } public function run() { $this->post->view->all(); } }//end class Blog

При создании класса Blog мы внедряем в него класс Post с Namespace BlogPost и автозагрузчик загружает его из Blog/Post/Post.php.
Наверное, этот класс и можно назвать Контроллером,

view = new View(); } }//end class Post

Сущность Post включает в себя:
- структуру самой записи данных - BlogPostEntitiesPostEntity.php

Службы, обслуживающие запросы Контроллера - BlogPostServicesView.php (одна из служб, для примера)

db = new DB(); }//end __construct public function all() { $posts = $this->db->survey(); Contemplate::compose(array("header" => "header", "main" => "main", "footer" => "footer",), array("posts" => $posts, "title" => "Viper site",)); } }//end class PostView

Систему взаимодействия с базой данных - BlogPostRepositoriesDB.php - вот она, наша тонкая, изящная Модель,
Только подай-принеси, и ничего больше!

dbh = new PDO("mysql:host=localhost;dbname=test", $user, $pass, array(PDO::ATTR_PERSISTENT => true)); } catch (PDOException $e) { echo "Error!: " . $e->getMessage() . "
"; die(); } }//end __construct public function survey() { $query_view = $this->dbh->prepare("SELECT * from posts"); $query_view->execute(); return $query_view->fetchAll(PDO::FETCH_CLASS, "BlogPostEntitiesPostEntity"); }//end survey }//end class Db

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

Не спорю, во многих случаях удобен фреймворк. Но, посмотрите, Namespace вам ничего не напоминает?
Четкое разделение на классы, строгая, и в тоже время гибкая, полностью подчиненная разработчику иерархия каталогов и классов.
Отсутствие порою такого весомого довеска в виде сотен файлов и классов в виде фреймворка.
Отсутствие прокрустова ложа правил взаимодействия классов и компонентов.

Статья навеяна размышлениями на эту тему Taylor Otwell, автора фреймворка Laravel, за что ему огромное спасибо.
Адрес исходников примера на GitHub.

Здравствуйте. В сегодняшней статье мы рассмотрим, что такое пространства имён в PHP .

Если вы давно используете ООП , то, наверное, встречали ситуацию, когда, подключая стороннюю библиотеку, у вас случался сбой из-за того, что вы уже используете в своём коде такие же имена классов, как и в библиотеке. Особенно это может случиться, если вы используете такие распрастранённые имена, как "model" , "db" и т.п. О том, как это исправить, я сейчас и расскажу.

Пространство имён(namespace) - это некоторое хранилище, созданное для абстрактной группировки уникальных идентификаторов(имён).

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

Создадим файл myclass.php с таким содержанием

namespace my\oneProject;
class MyClass { }
?>

Здесь мы создали класс в пространстве имён my\oneProject . Кстати, нужно писать именно обратный слеш. Не перепутайте!

Теперь в файле index.php напишем следующее

require_once("myclass.php");
$mc = new MyClass(); // Ошибка: класс не найден
$mc = new my\oneProject\MyClass(); // всё работает
?>

Как видите, теперь создать класс просто так не получится, нужно обязательно указывать, в каком пространстве имён он лежит.

Мы можем указывать сразу несколько пространств имён в одном файле

namespace Project;

Const CONNECT_OK = 1;
class Connection { }
function connect() { }

Namespace AnotherProject;

Const CONNECT_OK = 1;
class Connection { }
function connect() { }
?>

Не смотря на то, что у нас абсолютно идентичные названия классов, функций и констант, у нас не будет конфликта имён, т.к. они лежат в разных пространствах.

Мы можем также применять синтаксис со скобками.

namespace Project {

Const CONNECT_OK = 1;
class Connection { }
function connect() { }
}

Namespace AnotherProject {

Const CONNECT_OK = 1;
class Connection { }
function connect() { }
}
?>

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

namespace Project {

Const CONNECT_OK = 1;
class Connection { }
function connect() { }
}

Namespace { // глобальный код
session_start();
$a = Project\connect();
echo Project\Connection::start();
}
?>

Также, не забывайте, что определение пространства имён всегда должно идти первой строчкой кода. Если вы напишите так, то будет ошибка

Чтобы узнать, в каком пространстве имён вы сейчас находитесь, можно воспользоваться константой __NAMESPACE__

namespace Project;
echo """, __NAMESPACE__, """; // выведет "Project"
?>

С помощью данной константы можно, например, динамически конструировать имена

namespace Project;

Function incl($classname) {
$a = __NAMESPACE__ . "\\" . $classname;
return new $a;
}
?>

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

Недавно инкапсулировал свой проект в namespace и столкнулся с проблемой отсутствия нормальной документации. Все, что удалось найти датируется примерно 2009 годом, а на дворе почти 2012… В найденном материале куча нерабочих мест, использующих то, что в нынешней версии php нет. В связи с этим хочу немного осветить этот вопрос.
Итак, что же такое Namespace или пространство имен? Великая wikipedia определяет их так:

Пространство имён (англ. namespace) - некоторое множество, под которым подразумевается модель, абстрактное хранилище или окружение, созданное для логической группировки уникальных идентификаторов (то есть имён). Идентификатор, определенный в пространстве имён, ассоциируется с этим пространством. Один и тот же идентификатор может быть независимо определён в нескольких пространствах. Таким образом, значение, связанное с идентификатором, определённым в одном пространстве имён, может иметь (или не иметь) такое же (а скорее, другое) значение, как и такой же идентификатор, определённый в другом пространстве. Языки с поддержкой пространств имён определяют правила, указывающие, к какому пространству имён принадлежит идентификатор (то есть его определение).wiki

Все ясно? На самом деле все просто. До версии 5.3 в php существовало всего два пространства - глобальное(в котором выполнялся ваш основной код) и локальное(в котором определялись переменные функций).

С версии 5.3 все изменилось. Теперь можно определить свое пространство имен, в котором будут существовать ваши классы методы и т.д.


Надеюсь стало немного понятнее.

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

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

Внимание: по каким-то своим основаниям php не допускает использование ключевого слова use в блоках условий и циклах

Возьмем пример с картинок и воплотим его в коде:

Внимание: ключевое слово namespase должно быть расположено в самом начале файла сразу после
файл A.php
файл B.php
Возможен альтернативный синтаксис:
Рекомендуется объявлять каждое пространство имен в отдельном файле. Хотя можно и в одном, но это строго не рекомендуется!
Теперь переместимся в третий файл, в котором будет функционировать наш основной скрипт
index.php
казалось бы в чем преимущество, только кода прибавилось, однако это не совсем так, чуть дальше я приведу пример класса автозагрузки, с которым строки подключающие файлы с классами будут ненужны.
А теперь обратимся к нашим классам

Внимание: использование оператора разрешения области видимости (::) в пространствах имен php не допускается ! Единственное для чего он годится - это для обращения к статичным методам класса и константам. Вначале хотели использовать для пространства имен именно его, но затем из-за возникших проблем отказались. Поэтому конструкция вида A::A::say(); недопустима и приведет к ошибке.

Для пространств имен необходимо использовать символ обратного слеша "\"

Внимание: во избежание недоразумений необходимо экранировать данный символ при его использовании в строках: "\\"

Пространства имен можно вкладывать друг в друга, дополним наш файл A.php:
а в индексе напишем следующее:

Важным моментом является использование алиасов для импортированных пространств. Можно было написать A\subA::say(); согласитесь, каждый раз писать полные пути к пространствам затруднительно для того, чтобы этого избежать были введены алиасы. При компилировании произойдет следующее вместо алиаса sub будет подставлено A\subA, таким образом мы получим вызов A\subA::say();

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

Для того чтобы не было проблем с автозагрузкой классов из пространств файловую систему нужно организовать аналогично организации пространств. Например, есть у нас корневая папка classes, где и будут храниться наши классы, тогда наши пространства могут быть организованы следующим образом
classes\A\A.php
classes\A\sub\A.php(подпространство sub вынесем в отдельный файл)
classes\B\B.php

В php есть магическая константа __NAMESPACE__ которая содержит имя текущего пространства.

А теперь об автозагрузке.

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

Внимание: Для того, чтобы ваши классы загружались имя класса должно совпадать с именем файла!

" .$file ." in " .$filepath)); if (file_exists($filepath)) { if(Autoloader::debug) Autoloader::StPutFile(("подключили " .$filepath)); $flag = FALSE; require_once($filepath); break; } Autoloader::recursive_autoload($file, $path2, &$flag); } } closedir($handle); } } private static function StPutFile($data) { $dir = $_SERVER["DOCUMENT_ROOT"] ."/Log/Log.html"; $file = fopen($dir, "a"); flock($file, LOCK_EX); fwrite($file, ("║" .$data ."=>" .date("d.m.Y H:i:s") ."
║
" .PHP_EOL)); flock($file, LOCK_UN); fclose ($file); } } \spl_autoload_register("yourNameSpace\Autoloader::autoload"); }
Если посмотреть на имена классов, которые приходят для загрузки, то будет видно, что каждый класс предваряется префиксом из пространства имен, которое указано в use. Именно поэтому рекомендую использовать расположение файлов в каталогах аналогично пространству имен, это ускоряет поиск до одной-двух итераций.

Теперь наш индекс можно написать так:
теперь все классы и интерфейсы, которые вы будет использовать будут загружены автоматически.

Для демонстрации некоторых динамических возможностей языка с пространствами объявим еще один класс:
test.php

Index.php
sayName("test"); //а можно так test\sayName("test2"); //или так $obj::sayName("test"); //а можно так test::sayName("test2");

Надеюсь, что моя статья будет полезна кому-нибудь.

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

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

Имена: сфера описания данных и алгоритмов

Имена элементов (переменных, констант, объектов, функций и других конструкций разработчика) никогда не пересекаются. Любое совпадение имен 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 (пути + имена), можно управлять формированием пространств имен в процессе исполнения скрипта.

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

• Перевод
• Tutorial

Прим.пер.: Я в курсе, что на момент перевода актуальная версия PHP - 5.5, а также что есть мудрая книга мануал . Но мне показалось интересным, то как автор преподносит namespace функционал, возможно кому-то из тех, кто только постигает азы (да и не только, есть немало бородатых разработчиков, остановившихся на PHP 5.2), статья поможет проникнуться. Ходор.

В PHP, начиная с версии 5.3 появились пространства имен. Большинство современных языков уже давно заимели себе такой функционал, но PHP немного опаздывал. Тем не менее, у каждой новой функции есть свое предназначение, давайте выясним, какие выгоды мы можем извлечь, используя namespace.

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

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

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

Глобальное пространство имен

Вот такой, очень простой класс:
Ничего особенно, как видите, и если вы хотите использовать его, просто сделайте так:

Дейл, я как бы, знаю PHP...

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

Простое использование пространств имён

Давайте создадим еще одного Эддарда, рядом с тем, глобальным.
Здесь у нас очень похожий класс с одним небольшим изменением, добавлена директива пространства имен. Строка namespace Stark; говорит PHP что мы работаем в пространстве имен Stark и любой код (объявление классов, функций, переменных и т.д.) будет относиться к нему.

Итак, нам нужно создать нового Эдда, если вы решили что это нужно сделать вот так:
То нет, это не так. Здесь мы получаем экземпляр класса из первого примера, который мы создали ранее. Не тот, в пространстве имен Stark. Давайте попробуем создать экземпляр Эддарда Старка.
Для создания экземпляра класса нам нужно предварить имя класса префиксом из названия пространства имен, которому класс принадлежит, а в качестве разделителя использовать обратную косую черту . В итоге у нас есть экземпляр именно того класса, что нам нужен. Разве это не волшебно?

К слову сказать, пространства имён могут образовывать сколь угодно сложную иерархию, используя столько уровней, сколько потребуется. Например:
This\Namespace\And\Class\Combination\Is\Silly\But\Works

Теория относительности

Помните, как я сказал вам, что PHP всегда работает относительно текущего пространства имен. Давайте взглянем на это в действии:
Добавив директиву пространства имён, мы дали понять PHP, что мы находимся в пространстве имён Stark. Так как именно в нем мы определили класс Eddard, то именно его мы и получим. Видите - все относительно.

Сейчас, когда мы изменили пространство имён, у нас возникла одна маленькая проблема. Есть идеи, о чем я? А как нам теперь получить наш оригинальный класс Eddard? Ну тот, который в глобальном пространстве?

К счастью в PHP есть трюк, который позволит нам решить эту проблему - просто добавив \ к имени класса.
Видя ведущий слеш PHP понимает, что нужно выглянуть за пределы текущего namespace и создает экземпляр нужного нам класса.

А сейчас включи свое воображение. Представь, что у нас есть класс из другого пространства имен, названный Tully\Edmure. Сейчас нам нужно использовать его внутри пространства Stark. И как нам это сделать?

И снова нам пришлось использовать обратный слеш, чтобы перейти к глобальной видимости, прежде чем создать экземпляр класса в пространстве Tully.

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

Используя директиву use , мы можем получить класс из другого пространства имён. Только пожалуйста, не спрашивайте меня, «а почему мы не поставили здесь косую черту в начале?», потому что я просто не знаю. Насколько я знаю - это единственное исключение. Нет, вы можете использовать косую черту здесь. но смысла в этом не будет никакого.

А, еще один маленький трюк! Мы можем дать нашим импортируемым классам прозвища:
Используя ключевое слово as , мы присвоили классу Tully/Brynden прозвище Blackfish, что позволяет нам использовать новое прозвище для его идентификации в текущем пространстве имен. Ловко, не так ли? Это также очень удобно, если вам нужно использовать два класса, названных одинаково, в пределах одного пространства имён:

Давая Daenerys из пространства Dothraki прозвище Khaleesi, мы можем использовать оба класса Daenerys. Довольно удобно, там мы можем использовать все необходимые классы в нашем приложении.

Структура

Пространства имен также могут помочь нам в организации нашего кода. Позвольте, я продемонстрирую.

Скажем, я хочу создать библиотеку с открытым исходным кодом. Мне бы очень хотелось, чтобы другие могли использовать мой код, это было бы здорово! Беда в том, что имена классов в моем коде конфликтовали с собственным приложением пользователя моей библиотеки. Это было бы ужасно неудобно. Вот как я решу эту проблему:
Dayle\Blog\Content\Post Dayle\Blog\Content\Page Dayle\Blog\Tag
Здесь я использовал свое имя, чтобы показать, что код принадлежит мне, и отделить свой ​​код от кода пользователя моей библиотеки. Внутри базового пространства имен я создал структуру классов в соответствии с их иерархией.

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

Недостатки

По правде говоря, я чувствую себя немного виноватым за то, что назвал этот подзаголовок «Недостатки». То, о чем я собираюсь говорить, на самом деле ошибкой не является.

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

В Java, например, вы можете импортировать несколько классов в текущее пространство имен, используя оператор импорта. В Java, import является аналогом use и он использует точки, чтобы отделить вложенные пространства имен (или пакеты). Вот пример:
import dayle.blog.*;
Здесь произойдет импорт всех классов, находящихся в пакете ‘dayle.blog .

В PHP у вас так не выйдет. Вы должны импортировать каждый класс в отдельности. Извините. Собственно, почему я извиняюсь? Идите и жалуйтесь команде разработчиков PHP, но я прошу вас - будьте вежливы. Они сделали много интересного в последнее время.

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

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