Диагноз: Трейтизм

Всем привет.

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

Интересно? Тогда прошу под кат.

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

Как это было

Итак, в своё время, при разработке РНР 5.0 были введены классы, что стало самым значительным отличием пятой версии от четвёртой.
Классы привнесли свежий ветер в язык, сделав его ещё привлекательнее для программистов, заинтересованных в ООП.

Я застал этот переход и ещё больше вдохновился этим в чём-то парадоксальным языком.
Со временем я стал повсеместно замечать довольно странное использование классов — фанатическое внедрение ООП там, где оно, в принципе, не нужно.
Но я отвлёкся, вернёмся ближе к теме. Одна из проблем классов заключалась в том, что они практически не помогали решить вопрос повторного использования. Особенно это стало заметно среди -быдло-среднестатистического кода. Наследование, на мой взгляд, только усугубляло ситуацию.
В результате стали появляться классы-потомки, наделённые кучей методов, которые не используются. В добавок сильная связанность классов — стала нормой, которая маскировалась возможностью расширения и использованием своих «связок».

Чтобы как-то повлиять на сложившуюся сиутацию, в версии 5.4 были введены трейты (traits), также известные как примеси, миксины.
Суть достаточно проста: наконец-то появились концептуально корректные варианты добавить классу необходимую функциональность, не связывая его с другими классами.

Первые размышления

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

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

Результатом стала сборка класса из трейтов. Т.к. в трейтах позволяется определять и магические методы, то результирующий класс может быть ничем не обделён, по сравнению с «обычными» классами. А удобный синтаксис подключения трейтов, позволяет элементарно автоматизировать сборку.

Небольшой пример

Давайте я приведу небольшой фрагмент кода с подключением трейтов, чтобы было понятнее о чём я говорю:

<?php  require_once 'traits/Rivers.php'; require_once 'traits/Rocks.php'; require_once 'traits/Lands.php'; require_once 'traits/Sky.php'; require_once 'traits/Animals.php'; require_once 'traits/Birds.php'; require_once 'traits/PHP.php';  class World { 	use Rivers, Rocks, Lands, Sky, Animals, Birds, PHP; } 

Я специально привёл require, чтобы было видно, что трейты реквайрятся также, как классы. Ещё для наглядности приведу пример пары трейтов:

traits/Rivers.php:

<?php  trait Rivers { 	public $rivers = [];  	public function getRubyFromTheBottom(){...} }  

traits/Animals.php:

<?php  trait Animals { 	public $animals = [];  	public function drinkWater() 	{ 		if(!empty($this->rivers)) 			$water = array_shift($this->rivers); 	} } 

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

Что я хочу

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

Последнее условие решается тривиальным конфигом сборки в духе

<?php  return ["Rivers", "Rocks", "Lands", "Sky", "Animals", "Birds", "PHP"]; 

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

Я не буду приводить код сборщика — если кому-то интересно, пишите в личку: скину ссылку на проект сделанный в такой концепции.

Давайте пройдёмся по очевидным плюсам/минусам данного подхода, а потом я поделюсь немножко практическим опытом.

Минусы:

• Нет поддержки в IDE (пользуюсь штормом). Я имею в виду, что пока я не нашёл возможности подсказать шторму, что в данном трейте я использую метод из такого-то трейта (но машинально проставляю в докблоках use). Если кто-то знает, как решить эту проблему — буду рад комментариям (и добавлю в статью).
• Уничтожается смысл private и protected полей, т.к. класс у нас один. Минус, лично для меня, сомнительный, но всё же посчитал нужным его указать.
• Непривычное управление сборкой проекта. Да, по началу действительно странно, что настройка проекта сводится, по сути, к настройке сборки класса. Но потом привыкаешь и входишь во вкус (:
• Сложный контроль. Дело в том, что если в нескольких трейтах есть метод с одинаковым именем и вы не разрулили этот конфликт, то будет ошибка (правда она отловится в момент сборки, но всё равно неприятно).
• Что-то ещё из комментариев — уверен, что-нибудь подскажут.

Плюсы:

• Это новый, другой взгляд на разработку на РНР. Приносит своеобразный кураж, когда пробуешь новый подход, который не просто корректирует маршрут, а полностью меняет дорогу.
• Элементарны расширение и замена пластов функционала разного уровня. Подключаем трейт в сборку — оппа, у нас новый функционал, о котором наш «мир» ничего не знал. Например, беря классику жанра примеров — синглтон: подключаем трейт реализующий этот функционал и наш мир уже «одиночка». Заменили трейт и уже вместо json’a у нас используется yaml (см. пример под списком)
• Можно одновременно иметь несколько сборок с разным поведением. Удобно при тестировании: собрали несколько вариантов с разными модулями, запустили тесты и посмотрели, что эффективнее, корректнее и т.п. Кроме того, это может быть полезно при реализации функционала, подразумевающем роли/группы пользователей: для каждой группы можно собрать свой класс (в котором уже не будет проверок на роли и всего сопутствующего).
• Что-то ещё из комментариев — надеюсь, что-нибудь подскажут.

	trait Json 	{ 		public function getConfig(){...} 	}  	trait Yaml 	{ 		public function getConfig(){...} 	}  	trait Somewhere 	{ 		public function inTheCode(){... $this->getConfig ...} 	} 

Теперь предлагаю перейти к практическому опыту.

У меня имеется два проекта, которые я попробовал выполнить в данной концепции. При разработке я пришёл к следующим выводам/решениям/взглядам:

1. Элементарна поддержка событийной модели.

На данный момент в одном из проектов сделал так: у меня есть простая карта вида:

[ 	'событие' => ['слушатель', 'listener'] ] 

И во время срабатывания события происходит нечто подобное:

if(method_exists($this, $listener)) 	$this->$listener($context) 

Где контекст — это какие-то данные, которые сопутствуют событию.
Т.е. это тот момент, когда чувствуешь профит от того, что всё в одном классе.

2. Попробовал довольно странный метод хранения конфигов — тоже в трейтах.

Т.е. условно это выглядит так:

trait World_Config { 	public $worldConfig = [ 		// какие-то данные 	]; } 

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

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

Заключение

Думаю, для начала информации достаточно, чтобы поэкспериментировать (:

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

Если есть вопросы — задавайте, с удовольствием отвечу.

p.s. Если вы знаете какие-то рабочие проекты с подобной реализацией — пишите, буду рад добавить в статью.