Разработка внутренних компонентов RAD Framework... как PHP-разработчик с Nooku

У каждого свой набор инструментов. Как PHP-разработчик, я предпочитаю фреймворк для быстрой разработки приложений Nooku. По словам группы разработчиков: «Nooku — это скорее набор инструментов для веб-разработки, чем фреймворк».

Если вы не знакомы с ним, посмотрите. Это проект с открытым исходным кодом, в котором активно используются принятые в отрасли шаблоны проектирования для создания высококомпонентных приложений, легко расширяемых и пригодных для повторного использования (первоначально созданных одним из ведущих разработчиков Joomla!). По умолчанию Nooku предоставляет множество инструментов для быстрой разработки приложений, помогающих быстрее запускать проекты. Небольшой, но сильный пример:

• Реализация MVC по умолчанию, где все, что вам нужно сделать, это написать макет (это то, что меня зацепило)
• Доступность HMVC прямо сейчас
• Поддержка различных форматов вывода, таких как JSON и XML, для всех ваших данных (т. е. раскрытие вашего API за считанные минуты).
• Административные и интерфейсные реализации по умолчанию

В основе Nooku лежит принцип дизайна «Композиция важнее наследования» (фактически, это первая концепция на вводной странице Nooku. В одной строке: вы должны стремиться скомпоновать (или сложить) функциональность нескольких объектов, чтобы создать некоторые своего рода составной объект, а не полагаться на подклассы.

Этот принцип позволяет писать меньше кода и часто приводит к довольно элегантным решениям. Так как именно это продвигается? Что ж, на уровне кода лучшие примеры получаются при использовании миксинов и идентификаторов ресурсов/сервисов. Давайте взглянем.

Миксин

До PHP 5.4 в языке не было понятия Traits . Это классоподобные структуры, которые при «использовании» объектом предоставляют некоторую функциональность (аналогично множественному наследованию). Nooku годами решает эту проблему (начиная с PHP 5.2) с помощью Mixin .

Mixin не только позволяет вам объединять объекты, но также добавляет методы каждого смешанного объекта в интерфейс составного объекта. Объект, использующий миксин, кажется, «наследует» смешанные методы объекта.

 /** * Mixin an object * * When using mixin(), the calling object inherits the methods of the mixed * in objects, in a LIFO order. * * @param KMixinInterface $object An object that implements KMinxInterface * @return KObject */ public function mixin(KMixinInterface $object) { $methods = $object->getMixableMethods($this); foreach($methods as $method) { $this->_mixed_methods[$method] = $object; } // Set the mixer $object->setMixer($this); return $this; }

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

Основные классы в архитектуре контроллера Nooku также происходят от KObject. Абстрактный контроллер — это класс KControllerAbstract, и при осмотре вы можете увидеть, что он сразу же использует преимущества возможности микширования. Всякий раз, когда создается экземпляр этого класса, функциональные возможности KMixinCommand и KMixinBehavior немедленно добавляются к его интерфейсу. Следовательно, каждый контроллер в Nooku состоит из цепочки команд и функций управления поведением через соответствующие объекты.

Возвращаясь к контроллеру Nooku: класс KMixinBehavior содержит все части, чтобы дать KControllerAbstract возможность загружать определенные поведения во время выполнения. Поведенческие стратегии — это классы, описывающие процесс или логику, которые могут быть выделены и использованы другими классами (например, редактируемые, упорядочиваемые). KMixinBehavior довольно прост и имеет всего четыре метода: getBehavior, hasBehavior, addBehavior и getBehaviors. И это все, что нам нужно, чтобы дать объекту возможность обрабатывать и инкапсулировать различные поведенческие стратегии.

Точно так же KMixinCommand имеет только три метода: getCommandContext, getCommandChain, setCommandChain. Если вы не догадались, эти три метода предоставляют KControllerAbstract возможность реализовать цепочку команд, но позволяют делать это во время выполнения.

Вы можете думать об этом смешивании как о простом арифметическом сложении:

Дает нам интерфейс, который выглядит следующим образом:

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

Звучит круто. Но что это на самом деле означает? Короче говоря, Nooku предоставляет компонентную функциональность; то есть Nooku позволяет вам разбивать ваши функциональные возможности на модули и объединять функциональные возможности между модулями во время выполнения.

Эти два примера служат для демонстрации композиции. Они также служат для демонстрации того, что платформа Nooku RAD поддерживает дальнейшую композицию в своей основе. Это важное преимущество. Методы, добавленные в KControllerAbstract выше, поддерживают «Шаблон разработки стратегии», предоставляя разработчикам инструменты для инкапсуляции того, что изменяется, до того, как будет написана одна строка кода. Тот факт, что метод mixin() является частью каждого расширения KObject, означает, что вы можете легко определить и добавить другие интерфейсы управления поведением к большинству объектов во время выполнения.

Идентификаторы и локаторы сервисов и ресурсов: отделить имя моего класса от моего объекта

Идентификаторы и локаторы сервисов и ресурсов в Nooku также обеспечивают мощную поддержку разделения задач.

Опять же, давайте снова посмотрим на KObject, а также на KService. Мы можем обращаться с большинством вещей в Nooku как с сервисом или ресурсом, и поэтому создавать и опрашивать их точно так же.

Когда вы идете в продуктовый магазин и покупаете товар, думайте о магазине как об Услуге, т. е. о наборе товаров, которые вы можете просмотреть ; и продукт как Ресурс, т. е. логика одного элемента/решения, которая может быть:

• посмотрел конкретно ( прочитал ) (например, посмотрел на банку томатного супа)
• перемещаться по магазину ( E dited) (например, переносить суп в отдел продуктов)
• добавлено или удалено из инвентаря магазина (Добавить и Удалить ) (например, добавить новый вид супа и избавиться от помидора)

Продолжая этот пример, представьте, что в продуктовом магазине есть отдел франчайзинга, и вы хотите заниматься бизнесом. В этой ситуации Сервис — это отдел франчайзинга, а ресурс — продуктовый магазин, который вы покупаете. Это во многом контекстуальная классификация. В целом это известно как шаблон действия BREAD (вы увидите, что каждое из них представлено между KControllerService и KControllerResource с префиксом '_action', т.е. _actionRead()).

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

Каждый объект в Nooku представляет собой композицию объектов, каждый из которых содержит ссылку на службы, созданные для всего приложения, в «контейнере служб» и метод для доступа к службам, называемый getService(). Все, что требуется от метода KObject::getService(), — это передача действительного идентификатора ресурса, и он вернет экземпляр службы, готовый к использованию.

В быстрой разработке приложений PHP идентификаторы ресурсов дают нам мощный способ отделить создание экземпляра объекта от его имени класса и, таким образом, предоставить псевдонимы для этой идентификации. Это имеет важные последствия для удобства сопровождения приложения. С помощью псевдонимов разработчик может изменить класс, используемый каждым объектом, экземпляр которого создается с заданным идентификатором, добавив одну строку кода с помощью KService::addAlias().

Примером идентификатора ресурса, с которым мы знакомы, является URI или унифицированный идентификатор ресурса:

Это вся информация, необходимая KService для поиска и загрузки соответствующего класса. Эти части соответствуют соглашениям об именах и размещении классов Nooku, которые обеспечивают предсказуемость размещения и создания экземпляров. Пример идентификатора выше (com://site/user.database.table.user) пытается загрузить файл /components/com_user/databases/tables/user.php, который имеет имя класса ComUserDatabaseTableUser. Между прочим, если файл не существует, фреймворк предоставит вам объект таблицы по умолчанию и создаст его на основе соглашений об именах баз данных и схеме идентификаторов (это меня еще больше зацепило). Как упоминалось ранее, KService также позволяет вам устанавливать псевдонимы для ваших идентификаторов. Использование KService::setAlias('maindbaseadapter','com://admin/default.database.adapter.mysqli') ; позволяет нам загрузить объект базы данных с помощью KService::getService('maindbaseadapter') .

Это дает нам разделение, о котором мы говорили, и обеспечивает заметное преимущество в обслуживании и расширении наших приложений. Мы можем создавать приложения, отличные от «сайта» и «администратора», если это необходимо, и с помощью описанных здесь идентификаторов можем легко использовать службы, расположенные в других приложениях, чтобы помочь нашим решениям соответствовать их требованиям. Опять же, это еще один пример того, как Nooku предоставляет разработчикам и командам PHP и RAD поддержку композиции не только отдельных объектов класса, но и целых сервисов и приложений… бесплатно.

Подводя итоги

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