Когда пишут ООП-код, каждый класс помещают в отдельный файл. Класс может использовать какие-то другие классы. В примере ниже класс A
ссылается на классы SomeClass
и OtherClass
. Если класс SomeClass
не известен PHP, то на строчке class .. extends ...
интерпретатор выдаст ошибку. Аналогично, ошибка будет выдана, если мы вызвали метод test()
, но PHP в этот момент не знает о классе OtherClass
:
class A extends SomeClass
{
public function test()
{
$o = new OtherClass;
// ...
}
}
Чтобы код не выдал ошибку, мы должны в начале файла подключить (выполнить) файлы, где описаны классы SomeClass
и OtherClass
. Выглядит это примерно так:
// встроенная в PHP константа __DIR__ содержит путь к папке с этим файлом
require_once __DIR__ . '/Some/Class.php';
require_once __DIR__ . '/Some/Other/Class.php';
class A extends SomeClass
{
....
Конструкция require_once
выполняет код из указанного в ней файла, если этот файл ранее не подключался. Когда число классов увеличивается, писать все эти require_once
становится неудобно. К счастью, в PHP есть решение проблемы — автозагрузка, то есть автоматическая загрузка файла с классом при первом обращении к этому классу.
PHP позволяет тебе зарегистрировать функцию-автозагрузчик с помощью функции spl_autoload_register. Можно зарегистрировать любое число автозагрузчиков. В случае обращения к несуществующему в данный момент классу (о котором PHP ничего не знает), PHP будет вызывать по очереди все зарегистрированные автозагрузчики, передавая им имя класса. Если автозагрузчик знает, где лежит этот класс, он должен подключить файл с ним, PHP увидит, что класс появился, и продолжит выполнение программы. Иначе PHP вызовет следующий автозагрузчик. Если ни один автозагрузчик не подключит файл с классом, то будет выведена ошибка об обращении к несуществующему классу.
Вот примеры кода, который вызовет срабатывание автозагрузки:
// Будут вызваны все автозагрузчики для загрузки класса A
// Если ни один из них не найдет класс, то произойдет ошибка и
// выполнение скрипта прервется
$a = new A;
// Будут вызваны автозагрузчики для загрузки класса B
B::someMethod();
// Будут вызваны автозагрузчики для загрузки класса D
class C extends D
{
}
// Здесь тоже будут вызваны автозагрузчики для проверки, существует такой
// класс или нет, но даже если класс не будет найден, ошибки не произойдет,
// просто class_exists вернет false и код внутри if не выполнится
if (class_exists('E')) {
// ..
Бывает, что упоминание названия класса в коде не вызывает срабатывания автозагрузчиков. Вот пример, который приходит мне в голову:
function test(F $f) { }
Здесь в тайп-хинте упомянут класс F
, но PHP не будет пытаться его загружать, он использует лишь название класса для проверки типа переданного в функцию аргумента.
Автозагрузчиков может быть несколько. Например, если ты подключаешь стороннюю библиотеку, то она может зарегистрировать свой автозагрузчик для загрузки своих классов. Таким образом, каждая библиотека может самостоятельно решать, как она будет искать и подключать файлы.
Функция-автозагрузчик имеет такой вид:
function ($className) {
// ...
}
Она получает от PHP только имя класса. Для того, чтобы по имени класса можно было понять какой файл надо подключить, обычно используют либо заранее подготовленный список соответствия классов и файлов, либо придумывают договоренность, по которой из имени класса можно получить имя файла. Например, файлы называют так же, как и класс, с точностью до регистра букв, и кладут в заранее оговоренную папку: class SomeClass
описывается в файле SomeClass.php
. Одна из таких договоренностей называется PSR-4, о ней ниже.
Помни:
- автозагрузчик не должен выдавать ошибку, если он не может найти файл с классом - может быть, этот класс подгрузит следующий автозагрузчик
- пиши автозагрузчик только для своих файлов и не пытайся подгружать классы от сторонних библиотек - они сами об этом позаботятся
- не используй функцию
__autoload()
, она устарела много лет назад (например, она не позволяет сделать больше одного автозагрузчика) - в линуксе регистр букв в именах файлов имеет значение
- в PHP уже есть готовая реализация функции-автозагрузчика spl_autoload
- не изобретай свои правила сопоставления имен классов и файлов, а используй общепринятый стандарт PSR-4 (о нем ниже)
- вообще, автозагрузчик не обязан создавать класс именно за счет подключения файла, он может создать класс каким-то другим способом, например: искать код класса в базе данных, скачивать его с гитхаба, генерировать и выполнять с помощью конструкции
eval
. Но не стоит так делать, так как скорее всего твой код будет медленно работать и в нем потом будет очень сложно разобраться.
Пример функции-автозагрузчика:
spl_autoload_register(function ($class) {
// Получаем путь к файлу из имени класса
$path = __DIR__ . $class . '.php';
// Если в текущей папке есть такой файл, то выполняем код из него
if (file_exists($path)) {
require_once $path;
}
// Если файла нет, то ничего не делаем - может быть, класс
// загрузит какой-то другой автозагрузчик или может быть,
// такого класса нет
});
Подробнее про автозагрузку можно почитать тут:
- мануал: http://php.net/manual/ru/function.spl-autoload-register.php
- http://victor.4devs.io/ru/php/classes-autoload-php.html
- http://habrahabr.ru/post/136761/
Классы можно помещать в так называемые пространства имен (неймспейсы), иначе говоря, полное имя класса может состоять из нескольких частей, которые разделены бекслешем \
(не путай с прямым слешем /
). Например: в полном названии Megasoft\Megacms\SomeClass
слово SomeClass
- это короткое название класса, а Megasoft\Megamcs
- это пространство имен, в котором он находится. Уникальным должно быть только полное имя класса, а короткие названия могут совпадать, например: SomeLibrary\User
и OtherLibrary\User
.
Если в полном названии класса нет пространства имен, то полное название совпадает с коротким и говорят, что класс находится в корневом неймспейсе (например: ExampleClass
).
Неймспейсы, как и имена классов, принято писать с большой буквы.
Пространства имен позволяют записывать длинные имена классов в более удобном виде. Длинные имена появляются в коде по 2 причинам:
-
борьба с конфликтом имен. Представь, что Вася и Маша пишут каждый свою библиотеку и оба решают написать в них класс с одинаковым названием, например
User
. Или функциюgetUser()
. Если мы попробуем подключить в проекте обе этих библиотеки, произойдет ошибка, так как нельзя создать два класса с одинаковыми именами. Чтобы избежать таких конфликтов, нужно, чтобы имена классов были уникальными, потому библиотеки обычно приписывают к классам и функциям свое название в начало:Masha_User mashaGetUser() Vasya_User vasyaGetUser() Zend_Mail sfController
Если этого не делать, то конфликт обязательно будет, так как в мире тысячи библиотек, и в каких-нибудь двух обязательно будут совпадающие названия.
-
большие библиотеки и фреймворки состоят из большого числа классов (сотни и тысячи). Чтобы не запутаться, эти классы собирают в отдельные модули и добавляют имя модуля в начало имени класса. При этом сами модули могут быть дополнительно разделены на подмодули. В итоге получаются длинные имена классов:
Zend_Db_Table_Row_Abstract
— это класс фреймворка Zend Framework 1, модуль Db, подмодуль Table, подмодуль Row.sfDatabaseConfigHandler
— класс фреймворка Symfony1, модуль Database, подмодуль Config, класс Handler
Таким образом, разработчики вынуждены делать имена классов длинными. Это неудобно, так как они увеличивают длину строк и ухудшают читаемость кода, но без этого были бы конфликты и путаница.
Неймспейсы решают эту проблему тем, что позволяют составлять длинное имя класса из нескольких частей, но в коде использовать короткий, легко читаемый, синоним. Полные имена классов выглядят так:
Symfony\Component\Routing\Router
Doctrine\ORM\Mapping\Id
Masha\User
Vasya\User
Однако, писать полное имя в конструкции class X
нельзя. Чтобы поместить класс в неймспейс, мы должны указать в начале файла с ним название неймспейса с помощью ключевого слова namespace
. Неймспейс задается для всего файла сразу (это не проблема, так как мы обычно описываем в одном файле только один класс), и относится ко всем упомянутым в нем именам классов:
// Задаем пространство имен для этого файла
namespace MegaLibrary\Database;
// Указываем в конструкции class короткое имя класса
// Этот класс получит полное имя MegaLibrary\Database\User
class User
{
}
// PHP попытается создать объект класса MegaLibrary\Database\SomeClass
$x = new SomeClass;
Если в этом файле указаны другие имена классов, то PHP припишет название неймспейса перед ними: SomeClass
превратится в MegaLibrary\Database\SomeClass
, а название Connector\Db\Mysql
будет воспринято как указание на класс MegaLibrary\Database\Connector\Db\Mysql
.
Если мы хотим использовать класс из другого неймспейса, то мы должны либо указать его полное имя, добавив перед ним бекслеш (например $x = new \Other\Class(...)
или $y = new \Example
), либо задать для него синоним с помощью специальной конструкции use
, которая пишется в начале файла. Вот пример конструкции use
:
namespace MegaLibrary\Database;
// в этом файле Router - это синоним для длинного имени класса
use Symfony\Component\Routing\Router as Router;
$router = new Router();
Эта строчка говорит о том, что далее в коде название Router
будет обозначать класс Symfony\Component\Routing\Router
(иногда это еще называют "импортируем класс Router"). Если выбранный синоним совпадает с коротким названием класса, то конструкцию as
можно не писать, и код получается еще проще:
namespace MegaLibrary\Database;
use Symfony\Component\Routing\Router;
$router = new Router();
Конструкция use ... as
позволяет задать произвольный синоним для класса. Эта возможность используется, когда надо подключить классы с одинаковыми короткими именами из разных неймспейсов:
// Объявляем, что имя User будет обозначать класс \Some\Library\User
use Some\Library\User;
// Объявляем, что имя OtherUser будет обозначать класс \Other\User
use Other\User as OtherUser;
$user1 = new User;
$user2 = new OtherUser;
Таким образом, благодаря неймспейсам мы можем использовать длинные имена классов, не сильно ухудшая читабельность кода.
Часто неймспейс составляется из названия библиотеки или приложения, к которому добавляется группа или модуль, к которому относится класс. Неймспейс может состоять из произвольного числа частей, но на практике больше 2-3 уровней вложенности (не считая короткого имени) не требуется. Например:
Drupal\Core\Cache\MemoryBackend
- приложение Drupal, модуль Core, подмодуль Cache, класс MemoryBackendSymfony\Component\Routing\Router
- класс Router в фреймворке Symfony, в компоненте роутингаHashids\Hashids
- основной класс Hashids из библиотеки с таким же именем
Также, иногда главный класс может помещаться в корневой нейспейс, и обычно его название совпадает с названием приложения (чтобы гарантировать уникальность имен). Например, в Друпале есть класс Drupal
.
Если ты не указываешь в начале файла неймспейс, то твои классы создаются в глобальном, или корневом, неймспейсе (то есть класс SomeClass
получает полное имя SomeClass
). Подробнее неймспейсы и правила работы с ними описаны в мануале: http://php.net/manual/ru/language.namespaces.php
Повторим особенности неймспейсов:
- имена неймспейсов принято начинать с большой буквы.
- слова
namespace
иuse
пишутся в самом начале файла и действуют только в пределах этого файла. Они не влияют на другие файлы, которые могут вызываться из текущего. namespace
задает пространство имен для файла.use
задает короткий синоним для длинного имени класса.- в коде можно использовать полные имена классов, но перед ними надо поставить дополнительный бекслеш, чтобы указать, что к ним не надо приписывать текущий неймспейс.
- ради читаемости после слов
namespace
и группы словuse
оставляют одну пустую строчку - слово
use
не вызывает срабатывания автозагрузки и даже не проверяет, существует ли указанный в нем класс. Эта конструкция просто задает короткий синоним для длинного имени класса.
Современные IDE (вроде PhpStorm, Eclipse PDT или Netbeans) умеют вставлять в файл строку use
автоматически при использовании короткого имени класса. Не требуется писать ее руками. Некоторые IDE также умеют автоматически вставлять строку namespace
, определяя неймспейс по папкам, в которых хранится файл.
Хотя это редко используется, но функции и константы так же могут помещаться в неймспейсы и иметь длинные имена. Начиная с PHP5.6, их стало можно импортировать (создавать короткие синонимы) с помощью конструкций use function \Namespace\functionName
и use const \Namespace\CONSTANT
. Подробности описаны в официальном мануале PHP.
Некоторые утверждают, что переход на неймспейсы ничем не улучшает код: мы просто пишем use
в начале файла вместо require_once
. Но разница есть: мы можем использовать в коде более короткие названия классов, также мы убираем из кода информацию о том, в каком файле описан тот или иной класс.
Когда ты пишешь автозагрузчик, нужны какие-то правила, чтобы определить по полному имени класса путь к файлу с ним. Желательно, чтобы правила были общие, чтобы каждый разработчик не придумывал свой велосипед.
Эту проблему (как назвать файл с классом) решает рекомендация PSR-4 (англ). Она советует называть файл, взяв краткое название класса (с учетом регистра букв) и добавив к нему расширение .php
. Этот файл кладется в вложенные друг в друга папки, имена которых совпадают с частями неймспейса. Например, класс
MegaBlog\A\B\SomeClass
нужно поместить по пути
MegaBlog/A/B/SomeClass.php
Если проект хранится в папке c:/projects/mega
, и внутри нее мы создали для кода папку src
, то полный путь к файлу получается c:/projects/mega/src/MegaBlog/A/B/SomeClass.php
. Некоторые не используют папку src
, и кладут папку MegaBlog
сразу в корень проекта (в c:/projects/mega
).
Если в проекте все имена классов начинаются одинаково (например, они начинаются с MegaBlog\A...), то мы можем договориться не создавать для этих частей папки и положить класс MegaBlog\A\B\SomeClass
в c:/projects/mylib/src/B/SomeClass.php
.
Сам PHP не требует чтобы имя класса совпадало с именем файла, а имя неймспейсов - с именами папок. Ему не важно, где хранится класс. PSR-4 это лишь договоренность, чтобы все использовали общий стандарт.
Обычно в качестве неймспейса верхнего уровня выбирают название приложения, иногда вместе с названием компании или ником разработчика (например в фреймворке Symfony все классы лежат внутри неймспейса Symfony
). Если приложение маленькое, то все классы можно сложить в один неймспейс, а по мере роста добавляются дополнительные уровни вложенности и получится что-то вроде \Symfony\Component\HttpFoundation\Request
.
Если ты придерживаешься этого стандарта, то во-первых, ты молодец, во-вторых, ты можешь не писать свой автозагрузчик, а взять любой готовый автозагрузчик PSR-4 (например, встроенный в менеджер пакетов composer, который используется для установки сторонних библиотек и может заодно генерировать автозагрузчик). Единственное, что тебе надо указать — это корневой неймспейс твоего проекта и корневую папку. Вот пример кода, который надо вписать в файл конфигурации composer.json
, чтобы сказать, что классы из неймспейса MegaBlog\Core
находятся в папке src
, а классы из MegaPlugins
надо искать в plugins
:
{
"autoload": {
"psr-4": {
"MegaBlog\\Core\\": "src/",
"MegaPlugins\\": "plugins/"
}
}
}
Обрати внимание, что регистр тут имеет значение! Если ты напишешь PSR-4
вместо psr-4
, то composer просто тихо проигнорирует указанную тобой настройку, а ты будешь долго искать, в чем же проблема.
Мы пишем бекслеш 2 раза, так как таковы правила формата JSON (чтобы в строку вставить бекслеш, его надо написать 2 раза, бекслеш в JSON - это экранирующий символ). Бекслеш нужен, так как без него (если написать MegaBlog\Core
) правило будет относиться к любым классам, имена которых начинаются с этой строки, например MegaBlog\CoreSomething
.
В примере выше классы будут искаться так:
MegaBlog\Core\Some\Class -> src/Some/Class.php
MegaPlugins\Other\Class -> plugins/Other/Class.php
После того, как ты добавишь информацию в composer.json
, надо выполнить команду php composer.phar dump-autoload
или composer dump-autoload
(разумеется сам композер должен быть у тебя уже установлен). Она сгенерирует файлы автозагрузчика и положит их в папку vendor
. Тебе остается только подключить их в начале своей программы через require_once __DIR__ . '/vendor/autoload.php';
. Таким образом, следование PSR-4 и использование композера позволяет нам не писать свой автозагрузчик.
Официальная документация: