Пространства имен и автозагрузка в WordPress

На прошлой неделе я провел презентацию на WordCamp Atlanta, посвященную пространствам имен и автозагрузке. (полное название было «Пространства имен, автозагрузка и улучшение архитектуры подключаемых модулей», но это многословно, не так ли?)

Из-за характера выступления я решил написать сообщение, чтобы сопровождать сообщение, поделиться слайдами и поделиться примером плагина GitHub, чтобы помочь поддержать разговор.

Так что, если вы присутствовали, спасибо (!) и вот пост, который я обещал. А для тех из вас, кто не присутствовал, я надеюсь, что этот пост по-прежнему поможет продемонстрировать концепции и темы, которые я обсуждал на WordCamp.

Пространства имен и автозагрузка

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

В конце концов, не многие из нас, разработчиков, уже задают вопрос:

Как мы можем сделать наш код лучше, чем он есть?

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

Иногда у нас есть время исследовать способы сделать это; в других случаях мы работаем со знаниями, которые у нас есть. И в этом нет ничего плохого.

Но поскольку мы знаем то, чего не знаем, мы знаем, что есть потенциал для большего.

Во-первых, ваш код

Когда дело доходит до разговоров о таких темах, как пространства имен и автозагрузка в контексте WordPress, я думаю, мы часто сталкиваемся со смешанными ответами.

В конце концов, мы могли бы говорить о таких вещах, как Theme Customizer или REST API или о чем-то более интересном.

Я имею в виду, что «пространства имен и автозагрузка» просто не звучат захватывающе или прогрессивно по сравнению с более новыми функциями и доступными технологиями, верно?

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

Они не скучные

Я думаю, будет справедливо сказать, что разработчики — по крайней мере, часть из нас или часть из них, в зависимости от того, как вы себя видите — печально известны спорами об аспектах программирования.

— Все равно скучный разговор.

На самом деле, нередко можно услышать, как кто-то спорит о том, как лучше всего инициализировать и написать цикл for, который будет максимально производительным при переборе небольшого набора баз данных, несмотря на то, что у нас есть четырехъядерные процессоры и 16 ГБ ОЗУ. в наших настольных машинах.

Так что, если мы так заботимся о чем-то столь маленьком, то, конечно же, нас волнует более широкая картина. Такие вещи, как:

• Улучшенный код
• Лучшая организация
• Повышенная ремонтопригодность
• Упрощенная отладка
• Зарабатывать больше денег (ну, может быть).

А пространства имён и автозагрузка могут привести напрямую ко всему вышеперечисленному (ну, не могу говорить о деньгах, но потенциал у них есть).

Если бы мне нужно было обобщить пространства имен ролей и место автозагрузки во всем вышеперечисленном, я бы сказал, что:

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

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

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

Но это все еще не описывает ни одну из этих вещей. Но, безусловно, на данный момент они звучат более интересно, чем когда они были впервые представлены.

Итак, что они собой представляют?

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

Итак, давайте вернемся на мгновение и посмотрим на каждого из них в отдельности.

Пространства имен

Представьте, что вы унаследовали проект и собираетесь начать работу над ним. Скажем, это плагин WordPress.

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

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

Конечно, любое или все вышеперечисленное может способствовать проблемам с проектами WordPress. Но в большинстве случаев пространства имен действительно могут многое исправить.

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

Но когда вы создаете пространство имен, вы даете ему его область относительно самого себя, которая по-прежнему будет хорошо работать с другими компонентами, даже если они имеют одно и то же имя класса.

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

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

• включают
• include_once
• требовать
• require_once

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

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

Автозагрузка может решить все это, загружая зависимости, когда это необходимо (и для тех, кто заинтересован, автозагрузка быстрее, чем ручное включение).

Пространства имен

После всего сказанного мы готовы поговорить как о пространствах имен, так и об автозагрузке. Но пространства имен — это основополагающая концепция, поэтому мы начнем с них.

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

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

Руководство по PHP дает следующее определение :

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

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

Может быть, немного лучше?

Способ группировки связанных классов и интерфейсов, имеющих сходное назначение.

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

Практический пример

Мне не нравятся примеры программирования, которые не дают реального или практического применения. Часто нам приводят примеры вещей, которые мы никогда не систематизировали бы.

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

Скорее всего, мы будем работать с файлами. Итак, мы рассмотрим набор классов, отвечающих за чтение и запись файлов. Другими словами, мы были хорошими объектно-ориентированными программистами и разделили наши классы в зависимости от выполняемых ими обязанностей.

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

Итак, для нашего FileReader, возможно, основы класса выглядят так:

Класс для чтения файлов.

Обратите внимание, что функция принимает имя файла, который она должна открыть для чтения. Проверка ошибок, то, как он читает файл и что он возвращает, остается на усмотрение реализации класса.

А для FileWriter у нас есть что-то вроде этого:

Класс для записи файлов.

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

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

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

Примечания о пространствах имен

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

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

Запомнить:

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

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

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

Это означает, что наш FileReader теперь будет выглядеть так:

Класс с пространством имен для чтения файлов.

И наш FileWriter теперь будет выглядеть так:

Класс с пространством имен для записи файлов.

Во-первых, вы можете видеть, что использовать пространства имен очень просто: вы просто используете ключевое слово namespace, а затем объявляете пространство имен (которое также легко может быть WCATL) вверху, а за ним следуют подпакеты.

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

Об организации файлов

На этом этапе важно сказать несколько слов об организации файлов. В зависимости от того, с кем вы поговорите, вы обнаружите, что некоторые разработчики — сюрприз, сюрприз — имеют свое мнение о том, как должны быть организованы файлы (и я ничем не отличаюсь).

С одной стороны, вам вообще не нужно систематизировать файлы. На самом деле, вы можете поместить каждую вещь в корневой каталог вашего проекта, добавить информацию в пространство имен и быть готовым к работе.

Неорганизованные файлы

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

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

Здесь в игру вступают термины «логическая организация» и «виртуальная организация».

• Логическая организация относится к тому, как файлы организованы на диске, как вы видите выше. Они логически расположены в корневом каталоге.
• Виртуальная организация относится к тому, как файлы организованы относительно их пространств имен. Это означает, что существуют каталоги и подкаталоги, которые сопоставляются с пространствами имен, подпакетами и т. д.

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

Пространства имен и автозагрузка: организованные файлы

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

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

Примечания о пространствах имен

Однако что происходит, когда нам нужно создавать экземпляры классов с пространством имен? Когда классы не имеют пространства имен, легко использовать ключевое слово «новое».

Создание экземпляра без пространства имен.

Но мы должны создать экземпляр класса с пространством имен, мы должны сделать еще один шаг и использовать полное имя:

Пространства имен и автозагрузка: создание экземпляра с пространством имен.

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

С этой целью мы можем использовать то, что называется алиасингом. Это тоже просто. Мы можем определить использование ключевого слова «use» в верхней части файла для ссылки на пространство имен, которое мы хотим использовать как псевдоним, а затем использовать последний подпакет как часть псевдонима для создания экземпляра нашего класса.

Звучит запутанно, не так ли? Возможно увидеть это в действии поможет:

Псевдонимы пространств имен.

И это все, что нужно сделать. Да, вы можете пойти еще дальше, но это то, что я рассматриваю в контексте этой статьи.

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

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

Несмотря на это, самое важное, что нужно помнить о пространствах имен, на данный момент:

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

А теперь пора собственно взглянуть на автозагрузку.

Примечания к автозагрузке

Во-первых, давайте посмотрим на определение автозагрузки , данное в руководстве по PHP :

Функция spl_autoload_register() регистрирует любое количество автозагрузчиков, позволяя автоматически загружать классы и интерфейсы, если они в данный момент не определены. Регистрируя автозагрузчики, PHP получает последний шанс загрузить класс или интерфейс, прежде чем произойдет сбой с ошибкой.

Это не плохо. Зато длинно. Как и в случае с пространствами имен, давайте использовать для этой статьи более короткое определение:

Способ автоматической загрузки интерфейсов и классов без использования операторов include и require.

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

Практический пример

После того, как ваши файлы организованы, распределены по именам и готовы к загрузке, пришло время сделать именно это, верно? Я имею в виду:

1. ваши файлы организованы,
2. вы готовы загрузить их

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

Написание автозагрузчика

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

1. это не полностью автоматизировано,
2. мы должны написать это.

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

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

Шаги для автозагрузчика

При написании автозагрузчика нужно выполнить всего несколько шагов. Автозагрузчик должен отвечать на следующие файлы:

1. Где файлы?
2. Как они называются?
3. Файл существует?

Если все вышеперечисленное верно (или вы можете ответить «да» на все из них), то автозагрузчик сделает то, что должен.

Через некоторое время мы рассмотрим некоторый код, но первое, на что следует обратить внимание, это то, что в нем используется функция с именем spl_autoload_register.

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

Вот первая часть кода. Я объясню, что он делает постфактум:

Автозагрузка, часть 1 — поиск класса

В этой части кода функция получает полное имя класса, экземпляр которого нужно создать (например, «WCATLFileFileReader()»).

Затем он разделяет все части полного имени на части. Имя класса — это последний индекс массива, и я предпочитаю называть свои файлы «class-filereader.php», поэтому функция создает переменную $class_file, которая ссылается на имя файла.

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

Автозагрузка, часть 2. Получение полного имени

На этом этапе мы подготавливаем переменную $full_qualified_path, которая будет ссылаться на каталог верхнего уровня.

Затем код перебирает все индексы массива и создает путь к файлу класса. Вы можете представить это как создание строки, такой как «wcatlfile», которую мы затем объединяем с файлом $class_file.

Это означает, что полный путь к файлу становится «wcatlfileclass-filereader.php».

И, наконец, мы подключаем файл. Обратите внимание, что этот код не проверяет, существует ли файл. Хотя я рекомендую его, он был опущен из соображений длины и потому, что в нашем примере мы знаем, что файл существует.

Если файл не существует, есть несколько вариантов:

1. Бросьте исключение,
2. поймать исключение,
3. Отображение собственного сообщения об ошибке,
4. Или какой-то другой вариант, который я, возможно, рассматриваю в этой статье.

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

При автозагрузке

В заключение важно отметить следующее:

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

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

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

Наконец, другие могут использовать такие инструменты, как Composer, для добавления зависимостей. Это отличные инструменты, и в использовании чего-то подобного есть много преимуществ; однако это выходит за рамки концепций и тем этой статьи, и лучше оставить это для будущего разговора.

Ресурсы (и спасибо!)

Это была одна из самых длинных статей, которые я написал для своего сайта.

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

В дополнение к этой статье я также предоставил следующие ресурсы:

• Слайды моей презентации доступны на SpeakerDeck.
• У меня есть код из этой презентации, доступный для скачивания на GitHub.

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