How to become an author
Search
Write a publication
Pull to refresh

Comments 28

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

Сам пользуюсь Yii, там для этого используется Behavior. Позволяет добавить в класс новые поля и методы, а также повесить обработчики событий, если события определены в основном классе.
Total votes 6: ↑5 and ↓1+4
Да, реально если переделать эти плагины под декораторы, то гибкости прибавит на много больше (плагины смогут упралять контроллером напрямую), а простота увеличится:
new… ( new Plugin2( new Plugin1( new Controller ) ) )
Total votes 1: ↑1 and ↓0+1
На traits похоже.
Фактически паттерном это не является т.к. это всего лишь завуалированное наследование с динамикой, но очень похоже на Decorator, но в декораторе скрытые переменные остаются сокрытыми для декоратора
Хотя сам подход мне нравится, 5.3 в действии и оригинальное использование алиаса.
Total votes 3: ↑3 and ↓0+3
Ну насколько я понимаю тут скорее множественное наследование, нежели динамика.
This comment wasn’t rated yet0
Будда в треде! Все в машину!
Total votes 13: ↑9 and ↓4+5
В моём велике это тоже активно используется. Причём не только для контроллеров, но и для моделей.
Например, есть на сайте 3 списка: новости, события, мероприятия. Все они очень похожи, имеют по 15 полей и пачку связей. Но каждое отличается на одно поле (в мероприятиях нет анонса; а в событиях нет основной картинки-иконки). Вот тут на помощь приходят основные возможности ООПа: наследование, переопределение. Теперь, я делаю так:
Mydb::factory('BaseNews')->getAll(); // что бы получить все элементы.
Mydb::factory('BaseNews_News')->getAll(); // Только новости
Mydb::factory('BaseNews_Events')->getAll(); // Только события

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

С контроллерами точно так же.
Total votes 2: ↑0 and ↓2-2
Ну, используя и парся неймспейсы в моём велосипеде что угодно можно плагинизировать. Тут пытался привести простейший вариант, годный для дальнейшего затачивания под контекст.
This comment wasn’t rated yet0
Вообще то примеси и особенности(mixins и traits) отличная штука
Например если это идет на уровне языка то возможно писать так

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

class A {
use Singleton;
}

class B extends ArrayObject {
use Singleton;
}

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

Total votes 2: ↑2 and ↓0+2
В 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.
Total votes 5: ↑0 and ↓5-5
но обращаться придется к объекту класса «C», а если товарищи по кнопкам добавят своих классов? везде переписывать?
да и :: указывает на использование статичного метода. статичный метод это неплохо. в конкретном контексте…
Total votes 3: ↑2 and ↓1+1
Я совсем тебя не понял, что ты хочешь сказать.

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

Вызов через parent не является статическим вызовом
Total votes 2: ↑1 and ↓10
Пока я многословно промахивался этим, вы написали правильный комментарий.
This comment wasn’t rated yet0
Вы смеетесь? 


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 документацию.

Всё в результате получается просто, ясно и работает.
Total votes 3: ↑0 and ↓3-3
Сначала думал — как бы пообиднее подъебнуть вас, но потом понял, что это бессмысленно и незачем. Простите. Больше не буду тупить.
Total votes 7: ↑5 and ↓2+3
Включи strict-режим что ли. Пусть PHP сам расскажет тебе о том, как ты заблуждаешься.
Total votes 5: ↑5 and ↓0+5
Вопрос снят, заблуждался.
Total votes 2: ↑2 and ↓0+2
1., 2.: Есть массив кода. Везде прописано (например): $tSome = new A();
Добавилась пара плагинов — B и C, но обращения везде идут к A. Надо переписывать.

3. Не гони, бро.
Total votes 1: ↑1 and ↓0+1
На мой взгляд — какая-то хрень. Никакая IDE этого не поймет. Писать имена классов строками это вообще ппц. Рефакторинг пролетает. Лучше делать изначально расширяемые классы с хорошим набором событий.
Total votes 7: ↑6 and ↓1+5
Как это можно было бы использовать? Т.е. я вижу ответ на некий незаданный/подразумеваемый вопрос-проблему.
Что решаем?

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

This comment wasn’t rated yet0
В моем велосипеде используется система евентов, вместо плагинов:
Event::add( 'before.core.dispatch', 'somePlugin::action' );
Event::add( 'after.core.dispatch', 'somePlugin::action2' );
Total votes 1: ↑0 and ↓1-1
Имхо, Mixins и Traits — это «костыли» для реализации множественного наследования, которого нет в PHP (и хорошо). Опыт показывает, что в итоге от такого подхода отказываются с «взрослением» проекта и разработчика, который его пишет. Лучше использовать Decorator.
Total votes 1: ↑1 and ↓0+1
как приятно видеть код с таким объявлением переменных =) как родной язык прям =))
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr