Что такое Namespace Php

(PHP 5 >= 5.3.0, PHP 7, PHP 8)

Ниже приведён пример трёх вариантов синтаксиса в реальном коде:

namespace Foo \ Bar \ subnamespace ;

const FOO = 1 ;
function foo () <>
class foo
<
static function staticmethod () <>
>
?>

namespace Foo \ Bar ;
include ‘file1.php’ ;

const FOO = 2 ;
function foo () <>
class foo
<
static function staticmethod () <>
>

/* Неполные имена */
foo (); // определяется как функция Foo\Bar\foo
foo :: staticmethod (); // определяется как класс Foo\Bar\foo с методом staticmethod
echo FOO ; // определяется как константа Foo\Bar\FOO

/* Полные имена */
subnamespace \ foo (); // определяется как функция Foo\Bar\subnamespace\foo
subnamespace \ foo :: staticmethod (); // определяется как класс Foo\Bar\subnamespace\foo
// c методом staticmethod
echo subnamespace \ FOO ; // определяется как константа Foo\Bar\subnamespace\FOO

/* Абсолютные имена */
\ Foo \ Bar \ foo (); // определяется как функция Foo\Bar\foo
\ Foo \ Bar \ foo :: staticmethod (); // определяется как класс Foo\Bar\foo с методом staticmethod
echo \ Foo \ Bar \ FOO ; // определяется как константа Foo\Bar\FOO
?>

Пример #1 Доступ к глобальным классам, функциям и константам из пространства имён

function strlen () <>
const INI_ALL = 3 ;
class Exception <>

$a = \ strlen ( ‘hi’ ); // вызывает глобальную функцию strlen
$b = \ INI_ALL ; // получает доступ к глобальной константе INI_ALL
$c = new \ Exception ( ‘error’ ); // Создаёт экземпляр глобального класса Exception
?>

Источник

Что такое namespace php

(PHP 5 >= 5.3.0, PHP 7, PHP 8)

В PHP пространства имён используются для решения двух проблем, с которыми сталкиваются авторы библиотек и приложений при создании повторно используемых элементов кода, таких как классы и функции:

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

Пример #1 Пример синтаксиса, использующего пространство имён

namespace my \ name ; // смотрите раздел «Определение пространств имён»
class MyClass <>
function myfunction () <>
const MYCONST = 1 ;

$a = new MyClass ;
$c = new \ my \ name \ MyClass ; // смотрите раздел «Глобальная область видимости»

$a = strlen ( ‘hi’ ); // смотрите раздел «Использование пространств имён: возврат
// к глобальной функции/константе»

Замечание: Имена пространств имён регистронезависимы.

Названия пространств имён PHP и составные названия, начинающиеся с этих (такие как PHP\Classes ), являются зарезервированными для нужд языка и их не следует использовать в пользовательском коде.

User Contributed Notes 6 notes

Thought this might help other newbies like me.

Name collisions means:
you create a function named db_connect, and somebody elses code that you use in your file (i.e. an include) has the same function with the same name.

To get around that problem, you rename your function SteveWa_db_connect which makes your code longer and harder to read.

Now you can use namespaces to keep your function name separate from anyone else’s function name, and you won’t have to make extra_long_named functions to get around the name collision problem.

So a namespace is like a pointer to a file path where you can find the source of the function you are working with

Just a note: namespace (even nested or sub-namespace) cannot be just a number, it must start with a letter.
For example, lets say you want to use namespace for versioning of your packages or versioning of your API:

namespace Mynamespace\1; // Illegal
Instead use this:
namespace Mynamespace\v1; // OK

To people coming here by searching about namespaces, know that a consortium has studied about best practices in PHP, in order to allow developers to have common coding standards.

They are visible on this link : http://www.php-fig.org/psr

The ones I want to point are PSR-0 and PSR-4 : they use namespaces to resolve a FQCN (Fully qualified class name = full namespace + class name) into a file path.
Basic example, you have this directory structure :
./src/Pierstoval/Tools/MyTool.php

This might be the best practices ever in PHP framework developments, such as Symfony or others.

Источник

PHP NameSpace — как же все-таки его готовить?

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

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

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

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

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

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

— службы, обслуживающие запросы Контроллера — Blog\Post\Services\View.php (одна из служб, для примера)

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

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

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

Источник

Неймспейсы и автозагрузка в PHP

В этом уроке мы коснемся архитектуры приложений. Если быть точнее – мы научимся тому, как в современном программировании на PHP принято хранить классы в отдельных файлах, и о том, как избегать при этом бесконечных строчек с include и require для подключения этих файлов.

На самом деле, в PHP всё довольно просто с правилами по реализации большинства частей приложения. Для этого есть уже придуманные умными людьми стандарты – PSR (PHP Standards Recommendations). В них описано, как нужно писать ту или иную составляющую вашей программы.

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

Пусть у нас есть классы User и Article. Нам нужно сохранить их в разных файлах. Для этого давайте создадим рядом с папкой www папку src, а внутри неё папку MyProject. Внутри папки MyProject создадим папку Models, а в ней создадим ещё 2 папки – Articles и Users. И уже в этих папках создадим файлы Article.php и User.php. Должно получиться следующее:

Давайте теперь опишем в этих двух файлах наши классы.
src/MyProject/Models/Articles/Article.php

Первую часть сделали – теперь у нас каждый класс лежит в отдельном файле. Давайте теперь перейдём в наш index.php, лежащий в директории www и запишем в него логику для работы с этими классами.

Давайте теперь попробуем запустить этот скрипт в браузере.
Разумеется, мы получим ошибку.

Нашему скрипту не удалось найти класс User. Давайте подключим файлы с нужными нам классами в начале index.php

Если мы сейчас запустим этот скрипт, то всё у нас прекрасно отработает и мы увидим результат var_dump().

Итак, с первым пунктом про хранение классов в отдельных файлах мы разобрались.

Теперь вернёмся к пространствам имён – неймспейсам. Тут всё довольно просто – класс можно поместить в отдельное именованное пространство и в дальнейшем использовать его по этому полному имени. Для того чтобы указать это пространство для конкретного класса используется слово namespace, за которым следует само имя. Указывается оно в файле с классом, перед определением класса. На примере класса User это будет выглядеть следующим образом:
src/MyProject/Models/Users/User.php

Теперь мы можем говорить, что класс User находится в неймспейсе MyProject\Models\Users.

Давайте проделаем аналогичные действия с классом Article.
src/MyProject/Models/Articles/Article.php

Теперь, чтобы в файле index.php работать с данными классами, мы должны указать полное имя класса – это имя класса с указанием его неймспейса. Делается это следующим образом.
www/index.php

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

Но на этот раз, она уже другая. А именно – третий аргумент, переданный в конструктор класса Article должен быть объектом класса MyProject\Models\Articles\User, а передан объект класса MyProject\Models\Users\User. Заметили ошибку? Неймспейс не тот. Дело в том, что если в файле с классом указан неймспейс, то все классы, которые указываются в данном файле будут искаться в том же неймспейсе. Так как у нас класс User находится в другом неймспейсе, то мы должны явно это указать. Вот так:
src/MyProject/Models/Articles/Article.php

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

Теперь, когда мы будем использовать класс User, то автоматически будет использоваться класс из неймспейса MyProject\Models\Users\User.

Давайте снова запустим скрипт, и убедимся, что всё у нас теперь работает.

Получили работающий скрипт. Ура! Вот в принципе и всё, что вам нужно знать о неймспейсах. В наших будущих программах мы всегда будем создавать классы внутри неймспейсов.

Автозагрузка

Однако, давайте снова посмотрим на наш файл index.php. представьте, что у нас теперь большой проект и в нём больше 100 классов. Нам придётся сто раз писать require с указанием каждого файла. Утомительно, да? Однако, можно автоматизировать этот процесс, написав функцию автозагрузки классов. Она будет вызываться каждый раз, когда впервые будет встречаться новый класс.

Итак, давайте сделаем эту функцию автозагрузки. Давайте я сначала приведу пример кода, а затем объясню, как это работает. Наш файл index.php принимает следующий вид:

А теперь по порядку о том, что же происходит.

Всё! Теперь все классы будут подгружаться автоматически. Давайте запустим скрипт и убедимся, что всё работает.

Снова запустим скрипт и посмотрим на вывод.

Мы видим, что в эту функцию попал сначала класс MyProject\Models\Users\User, а затем MyProject\Models\Articles\Article. И для этих классов мы сделали require нужных файлов и они успешно подгрузились.

На этом давайте var_dump уберём.

В функцию spl_autoload_register можно и вовсе передать не имя функции, а прямо саму функцию – не будем сейчас на этом останавливаться более детально. Просто знайте, что так можно:

В таком случае, функция называется анонимной – у неё нет имени. Она просто передаётся в качестве аргумента и имя ей не нужно.

Запустите код ещё раз, и убедитесь, что всё работает как нужно.
Вот такими вот нехитрыми действиями мы сделали автозагрузку классов. PHP – прекрасный язык, не правда ли?

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

Источник

Как использовать пространства имен в PHP, Часть 1: Основы

Предисловие: На Хабре уже публиковались несколько статей, посвященных пространству имен в PHP (все ссылки на них я привожу в приложении). Однако, этот интересный и полезный вопрос был раскрыт не полностью. Поэтому я привожу перевод первой из трех статей по данной теме (остальные переведу в ближайшее время). P.S. Статья для начинающих

Пространства имен (namespaces) — это одно из самых значительных изменений в PHP 5.3. Они будут хорошо знакомы С# и Java разработчикам, и, вероятно, они изменят к лучшему структуру PHP-приложений.

Почему мы нуждаемся в пространстве имен?

Поскольку размер библиотеки Вашего PHP кода растет, возрастает и риск случайного переопределения функции или имени класса, которые были объявлены ранее. Проблема усугубляется, когда Вы пытаетесь добавлять сторонние компоненты или плагины; что будет, если два или более наборов кода будут выполнять классы «Database» или «User»?

Ранее, единственным решением были длинные имена классов/функций. Например, WordPress добавлял к каждому имени префикс «WP_». Zend Framework обычно дает детально описывающие названия, что приводит к длиннющим именам классов, таким как Zend_Search_Lucene_Analysis_Analyzer_Common_Text_CaseInsensitive.

Проблемы совпадения имен снимаются введением пространств имен. PHP константы, классы и функции могут быть сгруппированы в библиотеки пространств имен (namespaced libraries).

Как определяются пространства имен?

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

В коде, пространства имен определяются с помощью единственного слова namespace в самом начале Вашего PHP файла. Это слово должно быть самой первой командой (за исключением declare) и ни не-PHP код, ни HTML, ни даже пробел не должен предшествовать этой команде, например:

Весь код, следующий за этими строками, будет относиться к пространству имен «MyProject». Невозможно вкладывать в него другие пространства имен, или определять более чем одно пространство имен для одной и той же части кода (поскольку распознано будет лишь последнее объявление пространства имен, предшествующие же — игнорируются). Тем не менее, Вы можете определить различные пространства имен в одном и том же файле, например:

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

Подпространства имен (Sub-namespaces)

Вызов кода, относящегося к пространству имен

В файле с именем lib1.php мы определим константу, функцию и класс в пределах пространства имен App\Lib1:

lib1.php

Теперь мы можем включить этот код в другой PHP файл, например:

myapp.php

Никаких пространств имен не определено в файле myapp.php, поэтому код существует в глобальном пространстве. Любая прямая ссылка на MYCONST, MyFunction или MyClass вызовет сбой, поскольку они существуют только в пространстве имен App\Lib1. Чтобы вызвать код из lib1.php, мы можем добавить префикс \App\Lib1, чтобы определить полное квалифицированное имя. На выходе, когда загрузим myapp.php, мы получим следующий результат:

Полные квалифицированные имена могут становиться достаточно длинными; вместе с тем, существует несколько очевидных преимуществ в определении длинных имен классов, наподобие App-Lib1-MyClass. Поэтому, в следующей статье, мы обсудим использование псевдонимов (aliasing) и разберемся как PHP разрешает имена пространств имен.

Источник