Плагинизация классов

[megahertz]

Называется это по разному, реализация тоже отличается. Обычно Mixins (в PHP используется имитация), Behavior, для решения схожих задач немного другим способами также используют паттерны Decorator, Visitor и.т.п. Могу немного ошибаться, если что не так, буду рад поправкам.

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

[taliban]

Да, реально если переделать эти плагины под декораторы, то гибкости прибавит на много больше (плагины смогут упралять контроллером напрямую), а простота увеличится:
new… ( new Plugin2( new Plugin1( new Controller ) ) )

[tzlom]

На traits похоже.
Фактически паттерном это не является т.к. это всего лишь завуалированное наследование с динамикой, но очень похоже на Decorator, но в декораторе скрытые переменные остаются сокрытыми для декоратора
Хотя сам подход мне нравится, 5.3 в действии и оригинальное использование алиаса.

[nekt]

Ну насколько я понимаю тут скорее множественное наследование, нежели динамика.

[Zayaz]

Redhummer познает мир.

[redhummer]

Будда в треде! Все в машину!

[resurection]

В моём велике это тоже активно используется. Причём не только для контроллеров, но и для моделей.
Например, есть на сайте 3 списка: новости, события, мероприятия. Все они очень похожи, имеют по 15 полей и пачку связей. Но каждое отличается на одно поле (в мероприятиях нет анонса; а в событиях нет основной картинки-иконки). Вот тут на помощь приходят основные возможности ООПа: наследование, переопределение. Теперь, я делаю так:
Mydb::factory('BaseNews')->getAll(); // что бы получить все элементы.
Mydb::factory('BaseNews_News')->getAll(); // Только новости
Mydb::factory('BaseNews_Events')->getAll(); // Только события

ну и хранится всё это в одной таблице в которой есть столбец `type`.

С контроллерами точно так же.

[redhummer]

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

[dVaffection]

Как насчет применения этого?

[redhummer]

М?

[witdex]

Вообще то примеси и особенности(mixins и traits) отличная штука
Например если это идет на уровне языка то возможно писать так

trait Singleton {
public static function getInstance() {… }
}

class A {
use Singleton;
}

class B extends ArrayObject {
use Singleton;
}

A::getInstance();
B::getInstance();

[l2k]

В PHP для таких случаев есть одна интересная «форма»

class A{
   function hello(){
      echo "hello";
   }
}

class B{
   function hello(){
      echo "Dudes";
      A::hello();
   }
}

class C{
   function hello(){
      B::hello();
      echo "0_o";
   }
}

$c = new C();
$c->hello();

При вызове, классы B и A будут использовать $this от класса C.

[redhummer]

но обращаться придется к объекту класса «C», а если товарищи по кнопкам добавят своих классов? везде переписывать?
да и :: указывает на использование статичного метода. статичный метод это неплохо. в конкретном контексте…

[l2k]

Я совсем тебя не понял, что ты хочешь сказать.

1) Почему обращаться придется к объекту класса C? Обращайся хоть к B, хоть к A.
2) Что везде переписывать?
3) В твоем примере тоже статичные вызовы (правда parent).

[megahertz]

В вашем случае пропадают все прелести ООП.

Вызов через parent не является статическим вызовом

[redhummer]

Пока я многословно промахивался этим, вы написали правильный комментарий.

[l2k]

Вы смеетесь?

class A {function hello(){ /*...*/ }} 
class B extends A {function hello(){ A::hello(); }}
class С extends A {function hello(){ parent::hello(); }}
class D {function hello(){ A::hello(); }}

Если вы видите разницу между B и C и D — изучите PHP документацию.

Всё в результате получается просто, ясно и работает.

[redhummer]

Сначала думал — как бы пообиднее подъебнуть вас, но потом понял, что это бессмысленно и незачем. Простите. Больше не буду тупить.

[mdevils]

Включи strict-режим что ли. Пусть PHP сам расскажет тебе о том, как ты заблуждаешься.

[l2k]

Вопрос снят, заблуждался.

[redhummer]

1., 2.: Есть массив кода. Везде прописано (например): $tSome = new A();
Добавилась пара плагинов — B и C, но обращения везде идут к A. Надо переписывать.

3. Не гони, бро.

[mdevils]

На мой взгляд — какая-то хрень. Никакая IDE этого не поймет. Писать имена классов строками это вообще ппц. Рефакторинг пролетает. Лучше делать изначально расширяемые классы с хорошим набором событий.

[witdex]

Это называется типажы(traits) возможно будет нативная поддрежка в php 5.4. Смотрите тут simas.posterous.com/new-to-php-54-traits

[Roxis]

components.symfony-project.org/event-dispatcher/

[thecoder]

Как это можно было бы использовать? Т.е. я вижу ответ на некий незаданный/подразумеваемый вопрос-проблему.
Что решаем?

По поводу паттернов. Независимая обработка «событий» — это очень близко к подписке.
Объекты независимо реагируют на события :)

[taliban]

В моем велосипеде используется система евентов, вместо плагинов:
Event::add( 'before.core.dispatch', 'somePlugin::action' );
Event::add( 'after.core.dispatch', 'somePlugin::action2' );

[vooD]

Имхо, Mixins и Traits — это «костыли» для реализации множественного наследования, которого нет в PHP (и хорошо). Опыт показывает, что в итоге от такого подхода отказываются с «взрослением» проекта и разработчика, который его пишет. Лучше использовать Decorator.

[Becoming_Insane]

как приятно видеть код с таким объявлением переменных =) как родной язык прям =))