В этом уроке мы собираемся сделать перерыв в написании кода и посмотреть, что такое пространства имен PHP и автозагрузчики, как они работают и почему они полезны. Затем мы подготовим эту серию, внедрив их в код.
Если к этому моменту вы не освоились со всем, что мы рассмотрели в этой серии, я рекомендую вернуться и рассмотреть то, что мы уже рассмотрели. По крайней мере, просмотрите предыдущую статью, поскольку она заложит основу для того, о чем мы будем говорить в следующих двух статьях.
Теперь, когда вы оказались в курсе событий, вы знаете о плагине, над которым мы работаем, о том, что он делает и как он работает. Кроме того, у вас должна быть настроена локальная среда разработки, которая позволяет вам работать с исходным кодом. Если нет, вот краткое изложение всего, что вам нужно:
- Локальная среда разработки, которая включает PHP 5.6.20, веб-сервер Apache и сервер базы данных MySQL.
- Каталог, из которого размещается WordPress 4.6.
- Текстовый редактор или IDE на ваш выбор, которые вы можете использовать для написания плагина.
- Знание API плагинов WordPress.
Предполагая, что у вас все это установлено, настроено и готово к работе с последней версией плагина, мы готовы возобновить наше обсуждение пространств имен, автозагрузки и плагинов WordPress.
О пространствах имен и автозагрузке
Для тех, кто работал на других современных языках программирования, вы можете быть знакомы с концепцией пространств имен. Но даже если вы работали с PHP, маловероятно, что вы видели их много, по крайней мере, в контексте WordPress.
Для тех из вас, кто не слышал о них или кто слышал о них, но не использовал их, именно об этом и рассказывается в этой статье. В частности, мы поговорим о пространствах имен и автозагрузке, а затем, в следующем уроке, увидим, как все это сочетается.
То есть мы собираемся взять на себя работу, которую мы проделали с нашим плагином до сих пор, а затем обновить его, чтобы он использовал пространства имен и автозагрузку. Это даст вам практическое понимание концепций, а также несколько новых инструментов, которые можно добавить в свой репертуар для разработки при работе над следующим проектом.
Что такое пространства имен?
Как и в большинстве моих уроков, я хотел бы дать формальное определение, а затем разбить его на более разговорные термины. Руководство по PHP определяет пространства имен следующим образом :
В самом широком определении пространства имен являются способом инкапсуляции элементов.
Это не обязательно нам сильно помогает, не так ли? Можно утверждать, что классы делают то же самое, позволяя атрибутам и функциям быть обобщенными как элементы. Но руководство продолжается:
Пространства имен PHP предоставляют способ группировки связанных классов, интерфейсов, функций и констант.
Это немного понятнее, верно? Это означает, что когда у нас есть группа связанных классов, мы можем группировать их вместе в одном и том же каталоге или аналогичных каталогах в файловой системе, но это невозможно узнать, посмотрев на код.
Пространства имен дают нам возможность сделать это.
Подумайте об этом так: представьте, что у вас есть набор функций, связанных с работой с CSV.
- Возможно, у вас есть класс, который отвечает за чтение файла CSV, синтаксический анализ содержимого и чтение содержимого в массив.
- Затем у вас есть класс, который отвечает за перенос этого массива и запись данных в базу данных на основе содержимого этого массива.
- После этого существует класс, отвечающий за чтение этих параметров, когда сторонний объект или другая область в коде должны прочитать данные, которые были прочитаны, проанализированы и сохранены ранее в ходе выполнения проекта.
Вся эта функциональность должна охватывать несколько классов. В зависимости от того, насколько объектно-ориентированным кодом является ваше решение, у вас также может быть набор интерфейсов, реализуемых вашими классами. Кроме того, классы могут быть организованы в каталог /csv но разбиты еще дальше на свои собственные подкаталоги.
-
/read -
/write
Может быть, вы решили организовать структуру немного по-другому, но чтобы обсуждение было как можно более простым, я подумал, что это будет иметь смысл. Таким образом, возможно, интерфейс (ы) класса будет находиться в корне каталога /csv , читатель будет находиться в каталоге /read , а классы, отвечающие за запись данных в базу данных, будут находиться в каталоге /write .
Ничто из того, что я сказал до сих пор, не является необычным с точки зрения того, как мы можем организовать наши файлы. Но здесь вступают в игру пространства имен.
В частности, что если бы мы смогли организовать наши классы, чтобы они также отображались в их физическое местоположение в файловой системе?
Подумайте об этом так: допустим, ваш плагин называется Acme CSV, а все вышеперечисленные классы организованы в свои каталоги и подкаталоги и так далее. Как могут выглядеть пространства имен для этих классов и как они будут объявлены в проекте?
Взгляните на то, что мы будем называть классом Parser . Этот класс находится в /csv/read .
|
1
2
3
4
5
6
7
|
<?php
namespace Acme_CSV\CSV\Read;
class Parser {
// Class Implementation
}
|
А потом, скажем, у нас есть наш класс, который записывает данные в базу данных:
|
1
2
3
4
5
6
7
|
<?php
namespace Acme_CSV\CSV\Write;
class Serializer {
// Class Implementation
}
|
Наконец, давайте посмотрим, как выглядит пространство имен для класса, считывающего данные из базы данных:
|
1
2
3
4
5
6
7
|
<?php
namespace Acme_CSV\CSV\Read;
class Reader {
// Class Implementation
}
|
Ничего страшно сложного, правда? Хотя в приведенном выше стандарте нет необходимости организовывать файлы, я стараюсь сопоставить мои классы с их расположением на диске. Это облегчает обращение к ним в будущей работе.
На данный момент, на самом деле больше нечего видеть, кроме объявления типа организации ваших классов в начале их файлов. Но когда вы начинаете включать автозагрузку, это меняется.
Слово о пакетах и подпакетах
Прежде чем мы поговорим об автозагрузке, я хочу сделать небольшое отступление от @package и @subpackage которые мы так часто видим в комментариях к файлам.
Например, вы, вероятно, видели что-то подобное в отношении нашего кода выше:
|
1
2
3
4
5
6
7
8
|
<?php
/**
* This is the file comment for the Serializer class.
*
* @package Acme_CSV
* @subpackage Write
*/
|
Но когда вы обратитесь к документации phpDocumentor , вы увидите следующее о @subpackage :
Этот тег считается устаревшим и может быть удален в будущей версии phpDocumentor. Рекомендуется использовать возможность тега @package для обеспечения нескольких уровней.
Таким образом, @subpackage устарела, а это значит, что нам, скорее всего, не стоит больше его использовать. Как насчет тега @package ?
Тег @package используется для классификации структурных элементов на логические подразделения.
Поддержка многоуровневого размещения теперь находится исключительно в этом теге. Полезно знать, верно? Это означает, что код, который мы видим выше, может быть написан примерно так:
|
1
2
3
4
5
6
7
|
<?php
/**
* This is the file comment for the Serializer class.
*
* @package Acme_CSV\Write
*/
|
Конечно, это простой пример, но он имеет смысл. Я упоминаю об этом, потому что @subpackage — это еще один тег, который мы часто видим в PHP на основе WordPress, который нам следует избегать, если мы хотим начать принимать новые стандарты.
Что такое автозагрузка?
С учетом сказанного, давайте вернемся к основным темам под рукой. Поскольку мы рассмотрели пространства имен, давайте рассмотрим автозагрузку. Согласно руководству по PHP:
Многие разработчики, пишущие объектно-ориентированные приложения, создают один исходный файл PHP для каждого определения класса. Одним из самых больших неудобств является необходимость написания длинного списка необходимых включений в начале каждого сценария (по одному для каждого класса).
Это не может быть сказано лучше, не так ли? Тем не менее, это не совсем объясняет, что такое автозагрузка. Это просто объясняет проблему, которую он может решить.
В PHP 5 в этом больше нет необходимости … [он поддерживает загрузку] классы и интерфейсы для автоматической загрузки, если они в данный момент не определены.
Звучит фантастически, верно? Но есть предостережение, и мы собираемся изучить его подробно в следующем уроке. Но до тех пор вот оно: чтобы получить эту функциональность, мы должны реализовать функцию, которая знает, где искать файлы для загрузки и как анализировать структуру каталогов этих файлов.
Это звучит скучно, и в некоторых случаях это может быть, но если у вас есть последовательный способ организации вашей работы, ваш автозагрузочный код может быть переносимым. То есть вы можете взять написанную вами функцию, поместить ее в любой проект на основе PHP и быть готовым к тому же.
Но этот конкретный урок не о написании кода. Речь идет о рассмотрении идеи, лежащей в основе концепций кода, которые мы будем реализовывать в следующем руководстве.
Почему это важно?
В зависимости от того, кого вы спрашиваете, вы можете рассматривать пространства имен и автозагрузку как новые для PHP. Для некоторых это правда. Для других, они уже давно работают с этими двумя концепциями.
Одной из особенностей WordPress, которая может удерживать его от принятия новых функций PHP, является его приверженность обратной совместимости. Это не обязательно хорошо или плохо — это атрибут приложения.
Но поскольку WordPress имеет минимальную версию PHP, на которой он работает, новые языковые функции не всегда принимаются. И когда эта минимальная версия принята, разработчикам, специализирующимся на WordPress, требуется некоторое время, чтобы начать использовать эти функции в своем коде.
И это не плохо. Короче говоря, разработчики идут в ногу с приложением в темпе, в котором оно развивается.
Но так как WordPress продолжает двигаться вперед или у вас есть контроль над средой, в которой работает ваш проект, вы можете быть заинтересованы в использовании некоторых функций языка, которого вы ранее не знали, или который вы ранее не знали, были доступны.
Пространства имен и автозагрузка — это две мощные функции языка, которые делают код более читабельным, более организованным и даже более легким в обслуживании. Так что, если вы еще не используете их в любой своей работе в WordPress, особенно если вы работаете с плагинами WordPress, тогда я призываю вас рассмотреть возможность сделать это.
Вывод
Пространства имен дают нам возможность организовать наш код таким образом, чтобы упростить логическую группировку связанных классов. Кроме того, автозагрузка делает наш код более читабельным за счет уменьшения количества операторов include , include_once , require или require_once которые нам необходимо использовать.
Это делает исходный код, который мы пишем, более понятным, поскольку он сосредоточен исключительно на логике, за которую он отвечает, без необходимости делать что-то вроде импорта файлов, обрабатывать различные структуры каталогов и осознавать больше, чем следует (не говоря уже о разработчик должен постоянно перепечатывать все, чтобы иметь доступ к файлу).
А для тех, кто хочет убедиться, что структура их кода соответствует организационной структуре файлов и каталогов на диске, это дает нам возможность организовать наши проекты именно так.
Даже с учетом всего сказанного, это всего лишь один из способов и несколько преимуществ пространств имен и автозагрузки. Более сложные темы рассматриваются в руководстве по PHP и в других проектах с открытым исходным кодом, которые я рекомендую вам просмотреть, если у вас есть время.
В следующем уроке мы закончим эту серию, применяя то, что мы узнали из этого урока, когда мы представляем пространства имен и автозагрузку для нашего плагина WordPress. До этого, если вы ищете другие материалы, связанные с WordPress, вы можете найти все мои предыдущие учебники на моей странице профиля, а также подписаться на меня в моем блоге или в Твиттере .
Не стесняйтесь оставлять любые нерешенные вопросы о пространствах имен, автозагрузке или WordPress в приведенной ниже форме.