Constructor Dependency Injection и извращения

whirlwind

TDD infected, paranoid
и расширения по своей сути гавно не совместимое друг с другом. 100500 хуков которыъ все равно не хватает и приходится делать простыни копипаста оригинального кода (медиавики в том числе).

Наследование в данном случае - это не наследование как его применяют - это полная замена поведения части методов оригинального класса и чтобы это работало уже только с новым классом (оригинальный нигде в коде не используется только если вызов родителя). Т.е. фактически это композиция по существу, но в качестве инструмента использующая наследование (как костыльный инструмент). Т.е. фактически можно было просто генерировать итоговый файл с измененными частями кода и все. Но этот подход позволяет добиться того же самого без кодогенерации
Так а чем инжект сервис локатора не подходит я так и не понял? Один аргумент по соглашению. Наследуй хоть заунаследуйся.
 

Yoskaldyr

.
Партнер клуба
Так а чем инжект сервис локатора не подходит я так и не понял? Один аргумент по соглашению. Наследуй хоть заунаследуйся.
Так я создал тему чтобы не было сервис локатора, а полноценный конструктор инжектор, понятно что и то и то юзает контейнер.
Сервис локатор херово что слишком жадные зависимости получаются. А так сразу по конструктору видно что нужно данному классу.
Тупо удобство. Сервис локатор норм когда пишут нормальные разработчики, но очень часто получается как всегда. Если уж контейнер где-то явно понадобится то я его явно заинжектю через конструктор (типичный пример фабрики)

И пока есть 2 варианта которые решают эту проблему (да на рефлексии), в одном случае черная магия с yield для передачи $this контекста в другом немного более явно используя splat (...) оператор и да может кешироваться, так что рефлексия почти не будет влиять как во всех современных контейнерах умеющих кешировать скомпилированный конфиг.
 

Yoskaldyr

.
Партнер клуба
Если бы форум/смs былаб написано на хорошем массовом фреймворке, на той же симфони к примеру, то разработка плагина ничем не отличалась бы от обычного программирования.
Разовый продукт под конкретного заказчика - однозначно да. Здесь не нужна гибкость, а нужна четкая явность.
А когда речь идет о гибкости из разряда возможности вырвать зуб через анальное отверстие, то вот тут стандартные фреймворки требуют допила и иногда серьезного.
И если это было бы просто то хоть один такой продукт уже давно существовал, но это не так...

Вот почему тред называется так как он называется.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
знаешь, способов вырвать зуб через анус в php хватает, выбирай любой: yield, declare ticks, замыкания, new $factory($class)->$dep1($dep2,$dep3), include 'php://filter/
но если ты не пишешь фреймвок - можно только пожалеть
 

AmdY

Пью пиво
Команда форума
Фактически это не любимое наследование и является мидлварь подобной реализацией. Т.к. в 99% случаев все методы наследников состоят из собственного кода + вызов parent. Это ничем не отличается от мидлварьного next().
Мне кажется твоя ошибка в этом заблуждении. Ты пытаешься наследованием решить проблему, которая обязана решаться добрасыванием поведение в паплайн (мидлеварь). Твой плагин будет удобвлетворять интерфейсу плагинов и максимум может наследовать какой абстрактный класс из ядра системы, но никак не устраивать цепочки наследования с другими плагинами.
 
Сверху