Динамические примеси в PHP

Начиная с версии 5.4.0, в PHP появится новая конструкция языка — трейты (traits), реализующая возможность использования примеси (mix in). Механизм примесей является еще одним механизмом повторного использования кода и присутствует в том или ином виде в других языках, например, Ruby, Python, Common Lisp, etc.

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

Следует отметить, что реализации примесей в PHP существуют как минимум с версии 4.0.1, и в настоящее время присутствуют, чаще всего под именем behavior, в ряде популярных фреймворков, например, в Yii, Symfony, Doctrine, CakePhp, Propel.

Цель статьи — продемонстрировать и сравнить несколько основных подходов к реализации примесей в PHP до версии 5.4.0, базирующихся только лишь на функциях самого языка и не использующих сторонние расширения, как-то, например, функцию runkit_method_copy из PECL runkit.

При сравнении будут использованы следующие критерии:

• имеет ли результат микширования тот же тип, что и сам объект
• может ли одна примесь взаимодействовать с другой
• можно ли проверить, что результат микширования имеет ту или иную примесь
• можно ли добавить примесь к произвольному классу
• можно ли добавить примесь к уже созданному объекту “на лету”
• насколько проста реализация

Способ первый: Magic methods

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

Пример реализации:

abstract class Mixin {     protected $mixedObject = null;      public function setObject( MixedObject $object )     {         $this->mixedObject = $object;     }      abstract public function getName(); }  class MixedObject {     private $mixins = array();      public function addMixin( Mixin $mixin )     {         $mixin->setObject( $this );         $this->mixins[$mixin->getName()] = $mixin;     }      public function hasMixin( $mixinName )     {         return array_key_exists( $mixinName, $this->mixins );     }      public function __call( $name, $arguments )     {         foreach ($this->mixins as $mixin) {            if (is_callable( array( $mixin, $name ) )) {                return call_user_func_array( array( $mixin, $name ), $arguments );            }         }         throw new \Exception('Unknown method call.');     } } 

Пример использования:

class Foo extends MixedObject {     public function objectFunc()     {         return 'FooName';     } }  class Debuggable extends Mixin {     public function getName()     {         return 'Debug';     }      public function getDebug()     {         return sprintf( "%s", $this->mixedObject->objectFunc() );     } }  class Loggable extends Mixin {     public function getName()     {         return 'Log';     }      public function getLog( $level )     {         return $this->mixedObject->hasMixin( 'Debug' )             ? sprintf( "%s %s", $level, $this->mixedObject->getDebug() )             : sprintf( "%s", $level );     } }  $foo = new Foo(); $foo->addMixin( new Debuggable() ); $foo->addMixin( new Loggable() ); print $foo->getDebug(); print $foo->getLog( 'info' ); 

Очевидно, что результат имеет тот же тип, что и сам объект. Также данный подход оставляет возможность примесям общаться как с самим объектом, так и друг с другом, используя ссылку $this->mixedObject и систему уникальных имен.

Плюсы и минусы:

• [+] решение прозрачное и понятное
• [+] можно добавить примесь к уже созданному объекту, можно даже с использованным ранее именем
• [-] результат должен быть унаследован от класса MixedObject, таким образом, для использования микширования необходимо выделение иерархии типов
• [-] условие уникальности имен примесей требует постоянного внимания и здесь, возможно, будет нелишним введение каких-либо конвенций

Способ второй: Object context

Этот способ основан на некоторой особенности переменной $this. А именно:

$this is a reference to the calling object (usually the object to which the method belongs, but possibly another object, if the method is called statically from the context of a secondary object).

Выделенные слова дают возможность такой реализации:

class Foo {     public function objectFunc()     {         return 'FooName';     } }  class Debuggable {     public function getDebug()     {         return sprintf( "%s", $this->objectFunc() );     } }  class Loggable {     public function getLog( $level )     {         return is_callable( array( $this, 'getDebug' ) )             ? sprintf( "%s %s", $level, $this->getDebug() )             : sprintf( "%s", $level );     } } 

…и использования:

class MixedFoo extends Foo {     public function getDebug()     {         return Debuggable::getDebug();     }      public function getLog()     {         return Loggable::getLog( func_get_arg( 0 ) );     } }  $foo = new MixedFoo(); $foo->getDebug(); $foo->getLog( 'info' ); 

Далее нетрудно автоматизировать генерацию кода класса MixedFoo, последующий eval, создание объекта сгенеренного класса и его возврат, получая в итоге примерно следующее:

$foo = Mixer::Construct( 'Foo', array( 'Debuggable', 'Loggable' ) ); $foo->getDebug(); $foo->getLog( 'info' ); 

Также можно для каждой примеси сделать отдельный интерфейс и добавить в список implements для генерируемого класса.

interface IMixinDebuggable {     public function getDebug(); } ... $foo = Mixer::Construct( 'Foo', array( 'IMixinDebuggable' => 'Debuggable', 'Loggable' ) ); 

Это возможно, так как результат микширования будет реализовывать эти интерфейсы, и проверка на существование примеси тогда сведется к нативному вызову instanceof:

class Loggable {     public function getLog( $level )     {         return $this instanceof IMixinDebuggable             ? sprintf( "%s %s", $level, $this->getDebug() )             : sprintf( "%s", $level );     } } 

Плюсы и минусы:

• [+] нет необходимости наследовать расширяемый объект, таким образом, можно примешивать любые примеси к любым классам
• [+] в отличие от первого способа, “примешанные” методы получаются реализованными непосредственно в результате, поэтому не нужно тратить время на итерирование по коллекции, и код будет работать несколько быстрее
• [-] нет возможности расширить уже созданный объект произвольного класса
• [-] кодогенерация – это же отстой

Заключение

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

Если вынести результаты в отдельную таблицу:

	Magic methods	Object context
имеет ли результат микширования тот же тип, что и сам объект	Да	Да
может ли одна примесь взаимодействовать с другой	Да	Да
можно ли проверить, что результат микширования имеет ту или иную примесь	Да	Да
можно ли добавить примесь к произвольному классу	Нет	Да
можно ли добавить примесь к уже созданному объекту “на лету”	Да	Нет
насколько проста реализация	Проста и очевидна	Связана с генерацией кода

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

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

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

Спасибо.