вот увидеть бы 2 примера одного кода. Через Наследование и через композицию

композиция это не трейты

трейты ненужны

а есть статейка про то на что заменить абстрактные классы? вот не первый раз слышу, но никак не могу понять до конца альтернативу

давай от обратного - накидай случаи когда ты видишь пользу в абстрактных классах?)

"наследование классов нинужна!"

а если я придумаю кейс когда понадобиться?)

когда наследование нужно

реальный пример

а если я придумаю кейс когда понадобиться?)

скорее всего это будет какой-то мерзский кастыль что бы не дублировать свойства, но это шаринг стэйта, а шаринг стэйта "нужен" опять же только как кастыль (например сегодня доктрина только так могет)

ну тут дело не в стейте будет

ну тут дело не в стейте будет

если не в стэйте и весь стэйт приватный - непонятно зачем тебе наследование классов

вот давай реальный пример приведу

если не в стэйте и весь стэйт приватный - непонятно зачем тебе наследование классов

А почему нет)

давай от обратного - накидай случаи когда ты видишь пользу в абстрактных классах?)

давай. Есть AbstractFilter, который содержит базовые методы для построения фильтра. Что то типа квери билдера. И есть унаследованые OrderStatisticFilter, ProductStatisticFilter, etc...

А почему нет)

ну я только один повод могу придумать - ограничить кому можно доступ к методам замутить.... и это для параноиков

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

Базовые классы, естессна

в абстрактном есть общие для всех методы

давай. Есть AbstractFilter, который содержит базовые методы для построения фильтра. Что то типа квери билдера. И есть унаследованые OrderStatisticFilter, ProductStatisticFilter, etc...

заменяется композицией на раз

в абстрактном есть общие для всех методы

в 90% случаев эти общие методы там не нужны)

это как раз пример где можно наследование заменить легко композицией

а вот ситуация с твоим AbstractFilter и ты хочешь еще от кого то наследоваться (AbstractSorter)

вот тут твое наследование опечалит тебя а композиция обрадует

давайте я покажу плохой пример на ларавел на гитхабе. А вы скажете как было бы иначе

ща найду такой фильтр

ларавел сам по себе плохой пример, там много магии

ну я только один повод могу придумать - ограничить кому можно доступ к методам замутить.... и это для параноиков

Если стейт приватный, то минусов у наследованич становится на порчдок меньше. И выстрелить себе в ногу - невозможно

ща найду такой фильтр

все вызовы $this->method заменяешь на $this->filter->method в конструкторе создаешь $this->filter = new Filter;

Если стейт приватный, то минусов у наследованич становится на порчдок меньше. И выстрелить себе в ногу - невозможно

да

и все зарефакторено

ларавел сам по себе плохой пример, там много магии

да не важно это. В симфони тоже можно сделать плохо

ларавел сам по себе плохой пример, там много магии

и говна

это не исходники ларавеля

https://github.com/laracasts/Dedicated-Query-String-Filtering/blob/master/app/QueryFilters.php#L40

вот тут queryBuilder и методы строятся

вот тут queryBuilder и методы строятся

я написал выше

все вызовы $this->method заменяешь на $this->filter->method в конструкторе создаешь $this->filter = new Filter;

т.е. Внедрить как зависимость?

Фанатично отказываться от наследования я б не стал) а вот мозг включать, осознавая все риски - можно и нужно

Фанатично отказываться от наследования я б не стал) а вот мозг включать, осознавая все риски - можно и нужно

100%

Фанатично отказываться от наследования я б не стал) а вот мозг включать, осознавая все риски - можно и нужно

ну порой звучит так что это новая религия )))

т.е. Внедрить как зависимость?

нее тут это не проканает доступ к методам не будет

по хорошему тут надо агрегацию заюзать

вторым аргументом передать класс контекста

но тогда ты анемированную хуйню создашь

Фанатично отказываться от наследования я б не стал) а вот мозг включать, осознавая все риски - можно и нужно

ну ты ж понимаешь что это вопрос подачи, если говорить что "не ну в абсолюты скатываться глупо, надо думать" то народ в большинстве случаев это просто воспринимает как "ну короч плохо но похуй"

и по хорошему так лучше не делать

и не думает в итоге

но это позволит сделать без наследования

правда бывает и другая категория людей которые по итогу скатываются в абсолюты... хер знает как короч

еще правильней методы фильтрации в билдере должны быть

Если стейт приватный, то минусов у наследованич становится на порчдок меньше. И выстрелить себе в ногу - невозможно

А в чём минус протектед стейта? Подбивает на переопределение методов работы со стейтом в подклассах?

правда бывает и другая категория людей которые по итогу скатываются в абсолюты... хер знает как короч

Вот и надо про середину тереть, а не за крайности в стиле "в жопу наследование" или "акцессоры - рак")

еще правильней методы фильтрации в билдере должны быть

тогда мы приходим к Open/Close)

по хорошему тут надо агрегацию заюзать

есть пример кода с агрегацией, с композицией? любой пусть это будет исходник симфони.. чтобы протыкать все и осознать

Вот и надо про середину тереть, а не за крайности в стиле "в жопу наследование" или "акцессоры - рак")

не работает)

А в чём минус протектед стейта? Подбивает на переопределение методов работы со стейтом в подклассах?

Те, что не приватные, те финальные

есть пример кода с агрегацией, с композицией? любой пусть это будет исходник симфони.. чтобы протыкать все и осознать

https://pastebin.com/VGAuViNW

и теперь этот queryFilters можно впихивать в другой класс

и вместо $this->apply вызывать $this->filter->apply

только не забывать передавать контекст

но это так себе

и теперь этот queryFilters можно впихивать в другой класс

и как в каждом классе фильтра опрелять этот метод apply() ?

он ведь для всех классов одинаковый и получится дублирование кода

он ведь для всех классов одинаковый и получится дублирование кода

а с чего он одинаковый у всех ?

https://gist.github.com/fesor/66d2e328c47e7ad39a5a63329f64ab00

если наследник реализует интерфейс и использует метод предка для реализации это мягко говоря жопа

если наследник реализует интерфейс и использует метод предка для реализации это мягко говоря жопа

java c тобой не согласна)

ERROR: S client not available

ну так он одинаковый

мне нужен один и тот же метод в 5 подобных классах

чо делать

так то что он относится к интефрейсу

надо в QueryFilters написать implements ...

мне нужен один и тот же метод в 5 подобных классах

я не оч понимаю зачем он нужен

чтобы это показать

ну тоже самое к примеру с контроллерами

нафига абстрактный контроллер?

https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Controller/AbstractController.php#L37

нафига абстрактный контроллер?

Во имя лени

нафига абстрактный контроллер?

там много кода который шарится, бойлерплейт в основном

но поскольку задумка в том что там нет ни бизнес логики ни необходимости юнит тесты писать - в целом все счастливы. Хотя многие делают просто классы и инджектят зависимости туда. Например у нас так сделано сейчас

я правда к этому пока неоднозначно отношусь

https://github.com/mmasiukevich/saga/blob/master/src/Saga.php Пример абстрактного класса, в котором я особых проблем не вижу. Все на своих местах. Раскидывать где-то вне - не логично и нахер не нужно.

в целом.... у меня вот только апишки... а потому в контроллерах из зависимостей только пара сервисов которые нужны почти всем экшенам, остальные зависимости приходят в экшены контроллеров если нужны. А всякие там $this->json и т.д. я заменил на обработку результатов контроллера в листенере.

Коммент ток битый)

Копипаста - она такая)

https://github.com/mmasiukevich/saga/blob/master/src/Saga.php Пример абстрактного класса, в котором я особых проблем не вижу. Все на своих местах. Раскидывать где-то вне - не логично и нахер не нужно.

хз, на вскидку не вижу почему бы и нет)

хз, на вскидку не вижу почему бы и нет)

Это я к тому, что голова нужна не ток что бы в неё есть. Код не самый топчик, но в целом он безопасен

Если брать вашу реализацию, то у тебя, на скок я помню, всё в синглтоны вынесено. Эт мб и круто, но не в моем случае.

А вот так адекватно использовать подтипы? Фактически только для того, чтобы соблюсти прекондишены из предметной области. https://gist.github.com/Guuzen/142eca85899fee7fddf3a79bf0ea6af0#file-gist1-php-L183

А вот так адекватно использовать подтипы? Фактически только для того, чтобы соблюсти прекондишены из предметной области. https://gist.github.com/Guuzen/142eca85899fee7fddf3a79bf0ea6af0#file-gist1-php-L183

ну ты говоришь о контракте User который никакого отношения к иерархии типов Answer не имеет.

ну то есть да так можно, тут LSP нельзя нарушить потому что они и так разные типы

ну то есть да так можно, тут LSP нельзя нарушить потому что они и так разные типы

я больше о том, что: 1. У подтипов Answer-а нет никакого особенного поведения 2. В методе attachAnswer вообще не используется состояние User-а.

да и у подтипов Question тоже нет никакого особенного поведения

хз тут надо уже задачу понимать, но в целом выглядит это чуть странно

Всем доброго утра. У меня такой вопрос. Есть старая версия кода, в которой приходящий запрос фактически учитывается в 6 таблицах. Переписываю этот код и не до конца пойму как сделать лучше: создать 6 (не)репозиториев (gateway для общения с БД) или же все-таки 1, в которм собрать все запросы. В последствии, конечно, используются некоторые из gateway отдельно + как-то инжектить 6 нерепозиториев в класс выглядит убого.

Всем доброго утра. У меня такой вопрос. Есть старая версия кода, в которой приходящий запрос фактически учитывается в 6 таблицах. Переписываю этот код и не до конца пойму как сделать лучше: создать 6 (не)репозиториев (gateway для общения с БД) или же все-таки 1, в которм собрать все запросы. В последствии, конечно, используются некоторые из gateway отдельно + как-то инжектить 6 нерепозиториев в класс выглядит убого.

Обычно это признак того, что в твоей "модели" упущена сущность и она создаётся в рантайме на основе тех данных, так что надо глянуть на сущности которые есть. Один репозиторий на одну сущность, если у тебя 6 разных сущностей на одной странице то в чем проблема 6 реп. Другое дело если у тебя репорты или очень сложный ui там точно не надо использовать репозиторий

Там не репорты, а именно upsert - запросы. Сущности... Пример, просмотр новости пользователем при переходе через utm_* метки. У меня есть сущность Visitor, которая заполняется разными параметрами и VO (от агентов, браузеров до информацией о последнем заходе). Мне нужно на основании данных о пользователе и новости учесть запрос в таблицах: логи запроса, затраты, агрегированная статистика новостей, инкремент новости в самой таблице и т.д.

Получается, что в класc NewsLogger я должен заинжектить все необходимы gateway'ы?

ну у тебя будет сущность которая отдается и у нее свой mapper на бд