ради бога

не наследуйся от доктриновского репоса

он не для этого сделан

он может быть вполне себе абстрактным

и тогда ну просто вынужден

хоть сальто делай, а передать его не могу, только наследника)

ну просто профита от того, что я явно привяжусь к классу в конструкторе или в иерархии особо нет

ибо к интерфейсу привязаться все равно не могу

и мокать все равно придется со всем говном, что оно там несет в себе

final class Catalog { private $repository; public function __construct(EntityRepository $repository) { $this->repository = $repository; } public function add(Product $product) { } }

и пусть в EntityRepository будут дефолтные методы аля find или add или remove

а конкретика в Catalog

и опять же никакого наследования

и кода столько же

и руки развязаны

и цепочка связанности прервана

наша бизнес логика ничего не будет знать о EntityRepository

ну опять же, если EntityRepository абстрактный, то у тебя все равно всплывет его наследник)

он не абстрактный

так она итак не будет знать же?

он просто базовый

для всех доктриновских сущностей

это не тебе решать

мне)

а разработчику доктрины)

ну так он и решил)

замени доктрину, на другую ебанутую библиотеку

в которой решили иначе)

dependency inversion

и все будет хорошо

твоя БЛ все равно о нем не узнает

в том плане, что этот адаптер все равно где-то будет жить

какая разница?

если он используется где-то еще, то его есть смысл выделить от реализации интерфейса

потому что используется в двух реализациях

унаследовавшись от EntityRepository ты легко можешь нарушить LSP

если у тебя нет, то нет)

мм

типа если мои методы, будут ломать методы из ER?

ну вообще да

типа твои методы могут налагать больше ограничений, чем методы ER

ну или вообще другой интерфейс

да, логично

тип в ER у тебя "сохраню любую херню"

а ты такой "э не, только продукты"

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

ну да, согласен

а ты такой "э не, только продукты"

+++

я просто оставлял адаптерам единственное место, где наследование можно оправдать)

ну тут да, стоит их вывести в еще меньшее

@fes0r @mkusher спасибо, чуваки, хорошую дискуссию организовали)

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

то есть наследованию в нем нет места

@fes0r @mkusher спасибо, чуваки, хорошую дискуссию организовали)

всегда рады)

@fes0r @mkusher спасибо, чуваки, хорошую дискуссию организовали)

ееее)

Следил как за сериалом

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

чет я тупанул)

Следил как за сериалом

тут интерактив, все могут участвовать)

Не, отнаследовав по инерции студента и учителя от человека я просто решил наблюдать

@fes0r надо еще придумать хорошую задачку на полиморфизм

чтобы что-то очевидное давалось как if instanceof

Квадрат и прямоугольник)

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

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

и без наследования намного проще и чище

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

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

когда у тебя выбора нет

инфраструктура диктует свои правила)

ну вот с элоквентом хороший пример

там выбора реально нет

и без него реально сложно

ну точнее... реализация элоквента была бы раза так в полтора сложнее

ну понятно

тупо что бы дать возможность "не наследоваться"

когда все в неестественных позах, а в жопе кол

а если ты своих штуки делаешь - там наследование не нужно

опять же, я тоже не могу вспомнить ни одного случая когда "ну вот надо"

я же скидывал статью "Why extends is evil?"

опять же, я тоже не могу вспомнить ни одного случая когда "ну вот надо"

утром демо, а тут костылем все решается на раз два

я пропустил

Скинь ещё раз пжст