SP
по сути совокупность классов, засаппрешенных на уровне проекта - это своего рода антикоррупционный слой между говно-фреймворком (ларой в моем случае) и чистым ядром домена
только антикарапшена не случается)
Size: a a a
2020 December 21
АГ
да, все не предусмотришь. но более менее хотя бы держится проект. в классах, унаследованных от лара-классов, нет кода, и то слава Богу
DE
пхпстен предлагает делать методы вместо полей, раз, и абстрактное выносить в интрефейсы, два. это все изи фиксится. но когда наследуешься от классов фреймворка - деваться некуда, приходится саппресить на уровне проекта для определенного рода классов.
В этом и косяк. Фреймворки изначально пошли по пути наследования от контроллеров и других вещей. Но в новых трендах от этого уже можно уходить.
АГ
да, на самом деле это не сложно. единственная трудность - когда уже сотни тыщ строк плохого кода написано - задолбаешься переписывать. а когда удалось привести в порядок, поставить инструмент контроля с палкой - то уже не такая и беда, и пофиг по большому счету, лара, не лара...
ВУ
В этом и косяк. Фреймворки изначально пошли по пути наследования от контроллеров и других вещей. Но в новых трендах от этого уже можно уходить.
единственное, что очень сильно бесит в этом плане — это команды в симфони. остальное всё более-менее пишется без наследования
АГ
единственное, что очень сильно бесит в этом плане — это команды в симфони. остальное всё более-менее пишется без наследования
а зачем в них держать код?
АГ
у нас вот эти классы пустые, просто создают сервис и дергают
ВУ
в смысле? код я в них не держу, но команду-то надо написать
ВУ
там всё равно надо извлечь аргументы, параметры и так далее
ВУ
скажем, Action __invoke($a, $b): DTO в этом плане гораздо лучше выглядит
АГ
ну блин, совсем чтоли не писать классы, унаследованные от фреймворковских) это уже какой-то пуризм) написать класс на пару десятков строк стандартного бойлерплейта (объявить имя команды, описание) - вроде не проблема никакая
ВУ
скажем, Action __invoke($a, $b): DTO в этом плане гораздо лучше выглядит
ну вот тебе пример. ни наследования, ни констркутора — ничего не надо
ВУ
с командами тоже можно такое сделать, но лень
SP
вообще с точки зрения вещей которые флоу задают (команды те же) в целом наследование ок.
АГ
если так можно - супер
АГ
новые так - старые пусть остаются как есть, и делов
SP
вообще давайте честно - на код вот этой всей бойлерплейт трибухи вообще насрать
SP
счас бы фапать на чистоту подходов в бойлерплейте
АГ
кроме того можно еще потратить пару часов и старые команды переписать
АГ
если делать нечего