Длиннопост и немного баттхерта...
Я тут на днях посмотрел выступление Марко Пиветты
www.youtube.com
Хотелось бы обсудить выводы (само выступление разве что поржать, но лично мне интересен был конец с выводами). С одной стороны выводы очень красивые типа вообще не нужны DI контейнеры юзаем передачу всех параметров через конструкторы или аргументы методов и по факту получаем практически функциональное программирование (а если более точно то получаем True OOP то что активно пропагандирует Егор Бугаенко).
Все это хорошо на бумаге, и на небольших тестовых приложениях, но в реальном приложении получаем что абсолютно все зависимости, т.е. абсолютно все внутренности должны быть проинициализированы при старте приложения.
Пример (очень упрощенный):
на практике же будет совсем другое (названия классов совсем и тоже очень упрощенно, реальное дерево зависимостей всегда глубже раз в 5 и разветвленнее, особено когда используются стратегия или подобные паттерны):
В современных фреймворках это все реализовано через DIC и по факту все это дерево зависимостей создается используя магию рефлексии в DIC, но Марко говорит - нафиг контейнеры лучше писать явно. Но в результате получается нечитаемая каша в одном месте инфраструктурные внутренности в перемешку с доменной логикой. И все равно это не решает одной из главных проблем - создания и инициализации всего до того как в действительности оно будет нужно
(а очень часто оно как раз и не нужно). И самый прикол что как раз Марко написал куча разных либ для облегчения тяжелой инициализации (тяжелая в плане времени выполнения, например, различные коннекты к БД, сокетам и т.д.) - разные прокси фабрики, constructorless фабрики, генерируемые фабрики, как раз чтобы избавится от тормозов тяжелых конструкторов до реального их использования класса. Но все это у него как раз и основано на магии и на неявном коде (типа делаем "явно" в одном месте, но делаем кучу магии в другом).
Т.е. с одной стороны все красиво в теории, но практике будет полная хрень. Я хочу заметить, что Марко предлагает полностью отказаться от DIC и передавать все зависимости явно (функциональный стиль). И это реально красиво, но только в теории или на очень небольших приложениях с минимальным деревом зависимостей
И как мне кажется, т.к. Марко - один из ведущих разработчиков в php коммьюнити, то с большой вероятностью подобные начинанию пойдуи проникать активно во фреймворки и т.д.
Лично я считаю что такой подход хорош для группирования больших структурных блоков приложения, а каждый блок уже сам решает как ему внутри создавать зависимые классы - хоть вообще без всяких контейнеров или магии - тупо через new. Для тестов в таких случаев есть softMocks и аналоги. Зато код получается в разы чище и читаемее. Хотя конечно это идет в разрез с "современными практиками".
Чтобы было понятно в примерах кода Марко как раз использует мидлвари как группировку верхнего уровня, но вот голосом говорит, что передавайте все зависимости явно, а не через DIC. Т.е. на слайде более менее красиво, на голосом советует немного другое...
И в завершении,
Вы все ещемоете обычным порошком используете DIC? Если да, то Марко идет к вам!
Я тут на днях посмотрел выступление Марко Пиветты
- YouTube
Смотрите любимые видео, слушайте любимые песни, загружайте собственные ролики и делитесь ими с друзьями, близкими и целым миром.
Хотелось бы обсудить выводы (само выступление разве что поржать, но лично мне интересен был конец с выводами). С одной стороны выводы очень красивые типа вообще не нужны DI контейнеры юзаем передачу всех параметров через конструкторы или аргументы методов и по факту получаем практически функциональное программирование (а если более точно то получаем True OOP то что активно пропагандирует Егор Бугаенко).
Все это хорошо на бумаге, и на небольших тестовых приложениях, но в реальном приложении получаем что абсолютно все зависимости, т.е. абсолютно все внутренности должны быть проинициализированы при старте приложения.
Пример (очень упрощенный):
PHP:
$route('/form')->pipe(
new AuthMiddleware(),
new CheckFormData(),
new DomainMiddleWare(),
new SomeOtherMiddleWare(new SomeDes(), new OtherDeps())
);
PHP:
$dbConnection = new DbConnection();
$config = new Config($dbConnection);
$route('/post-create')->pipe(
new AuthMiddleware(new AuthProvider($config, $dbConnection)),
new CheckFormData(new Form1Class(
new FromDeps1( new FormDepsDeps ()),
new FromDeps2($config)
)),
new DomainMiddleWare(),
new SomePostMiddleWare(
$config,
new PostCreate(
new UserFactory($config),
new PostFactory(
new ThreadFactory(
new CategoryFactory($config),
$config),
$config),
new OtherDeps1(),
new OtherDeps2(),
)
);(а очень часто оно как раз и не нужно). И самый прикол что как раз Марко написал куча разных либ для облегчения тяжелой инициализации (тяжелая в плане времени выполнения, например, различные коннекты к БД, сокетам и т.д.) - разные прокси фабрики, constructorless фабрики, генерируемые фабрики, как раз чтобы избавится от тормозов тяжелых конструкторов до реального их использования класса. Но все это у него как раз и основано на магии и на неявном коде (типа делаем "явно" в одном месте, но делаем кучу магии в другом).
Т.е. с одной стороны все красиво в теории, но практике будет полная хрень. Я хочу заметить, что Марко предлагает полностью отказаться от DIC и передавать все зависимости явно (функциональный стиль). И это реально красиво, но только в теории или на очень небольших приложениях с минимальным деревом зависимостей
И как мне кажется, т.к. Марко - один из ведущих разработчиков в php коммьюнити, то с большой вероятностью подобные начинанию пойдуи проникать активно во фреймворки и т.д.
Лично я считаю что такой подход хорош для группирования больших структурных блоков приложения, а каждый блок уже сам решает как ему внутри создавать зависимые классы - хоть вообще без всяких контейнеров или магии - тупо через new. Для тестов в таких случаев есть softMocks и аналоги. Зато код получается в разы чище и читаемее. Хотя конечно это идет в разрез с "современными практиками".
Чтобы было понятно в примерах кода Марко как раз использует мидлвари как группировку верхнего уровня, но вот голосом говорит, что передавайте все зависимости явно, а не через DIC. Т.е. на слайде более менее красиво, на голосом советует немного другое...
И в завершении,
Вы все еще
аналогично лишняя сущность
