хотя не

нифига

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

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

так что не, тут ты нарушил предусловия и нарушил контракт

abstract public function addPayment( int $payment_id, Item $item ) : Payment а в стратегии $payment_id строка(

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

они приводятся к строкам спокойно. Но вот обратно уже не так прикольно

так возвращает payment api gateway

payment_id по логике вещей не может быть интом уже очень-очень давно)

ну понятно, что приводятся, но мы все же говорим о некотором полиморфизме

abstract public function addPayment( int $payment_id, Item $item ) : Payment а в стратегии $payment_id строка(

сделай так что бы приходили строки

ну вот так и пришлось сделать

ну понятно, что приводятся, но мы все же говорим о некотором полиморфизме

с точки зрения клиентского кода все ж хорошо)

и пускай твоя реализация уже сама решает, как передавать

ну вот так и пришлось сделать

ну так 7.2 тебе тут не поможет

ну так 7.2 тебе тут не поможет

почему же?)

если у меня в родителе int

а в потомке string)

почему же?)

потому что тебе не надо "убирать" предусловия. Тебе надо для всех реализаций на строки переделать

было)

ну да, ты прав

было)

то ты сломал LSP

если у тебя разные ограничения на ID для разных платежных сервисов - ты уже по сути прогррал немного)

и тебе надо реально заводить VO который будет заниматься валидацией

ну короч... сложно все

тут надо уже смотреть какой контракт нужен клиентскому коду

а вот еще, вопрос в именовании. есть тупая вендорская либа, для платежки работает она так new Client(new Config()) и в конфиге охринеть кол-во параметров строками передаются я обычно в таком случае брал их и собирал в класс конфига, а тут он уже существует ? пол дня думать как назвать по сути тупую структуру данных которые можно скормить конфигу

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

вендорская либа... сделать ей фабрику или в контейнере описать и не делать руками

нужно ли пользоваться интерфейсами репозиториев? если да - в каком слое их хранить? сейчас они у меня в доменном слое (хоть и некошер)

нужно ли пользоваться интерфейсами репозиториев? если да - в каком слое их хранить? сейчас они у меня в доменном слое (хоть и некошер)

интерфейсы репозиториев в доменных слоях это кошерно. Не кошерно это реализацию туда ложить

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

окей, в таком случае реализация в слое приложения? или в слое фреймворка? (не вижу смысла отдельно заводить слой инфраструктуры под доктрину)

реализация репы это инфраструктура. То есть в твоем случае да, можно назвать это фреймворк

окей, в таком случае реализация в слое приложения? или в слое фреймворка? (не вижу смысла отдельно заводить слой инфраструктуры под доктрину)

ну у тебя другая инфраструктура 100% есть помимо доктрины)

p.s. я ленивый и не выделяю интерфейс у репозитория и ложу его там же где и домен... и мне стыдно

окей, и третий вопрос насколько гуд/не гуд реализовать (это уже под симфони) репы не через наследование, а через композицию? (недавно статейка проскакивала)

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

окей, и третий вопрос насколько гуд/не гуд реализовать (это уже под симфони) репы не через наследование, а через композицию? (недавно статейка проскакивала)

отличная идея, я так и делаю)

EntityRepository - это общий интерфейс, его надо "спрятать" под специализированный

адаптер эдакий

все равно доменные модели - это и есть сущности доктрины, в любом случае происходит смешивание инфраструктуры и домена в симфони

другая инфраструктура - ее слишком мало, чтобы выносить в слой)

все равно доменные модели - это и есть сущности доктрины, в любом случае происходит смешивание инфраструктуры и домена в симфони

сущности твои а не доктрины. Они не принадлежат ей.

это полностью твои классы и все такое. А doctrine/collection - представь что это тебе язык предоставляет)

Что такое ioc? И чем отличается от di и dip? Смотрел хабр, кто в лес, кто по дрова

ioc - это принцип. DI - это реализация принципа

https://ru.wikipedia.org/wiki/Внедрение_зависимости

пример ioc - у тебя есть фреймворк который дергает твой код. Например - пришел http запрос и твой фреймворк дернет твой обработчик а не обработчик попросит фреймворк чего-то сделать. То есть происходит инверсия направления потока управления (кто кого вызывает). пример di - это вариант ioc при котором тебе сделают зависимость а не ты будешь это делать. Пример dip - это когда у тебя есть 2 модуля, один зависит от второго. Но ты не хочешь что бы он зависел от него, и делаешь интерфейс, дабы модуль начал зависеть от интерфейса и таким образом мы изменим направление зависимости.

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

ioc - про инверсию управления (кто кого вызывает) а dip про инверсию зависимостей (кто от кого зависит)

ну то есть ioc и dip это разные штуки, и ioc это не только про то как сервисы сделать, а di только про это

Понятно, а вот в русской wiki про методы реализации есть пункт: Контекстный поиск (англ. contextualized lookup) Что это за зверь такой? О.о

ну почитай)

вариантов сделать ioc в разных контекстах много)

Понятно, спасибо:)

главное понять суть - зачем.

и будет проще

а есть принцип ООП, который звучит как "не делай лишних движений"?

ооп и программирование это разные понятия

ок, подловил

принцип программирования

ERROR: S client not available

но так ты не продашь

kiss какой-нибудь

ну это то да... но его тоже не продашь :(

а кому ты его хочешь продать?

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

типа мол почему я выпилил нахрен эту константу

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

+ сложность реализации новых фич

во! технический долг я продам

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

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

жестоко

жестоко

я просто не свой код рефакторю, и они могут сопротивляться

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

на этом днище просто ничего нельзя сделать нормально

а есть принцип ООП, который звучит как "не делай лишних движений"?

Yagni?)

да, хорош

а накидайте еще каких-то принципов, которые не входят с солид, но важны (ваше мнение)

https://www.slideshare.net/khokhlova1991/ss-19053261

25 слайд и дальше

запись доклада гуглится, рекомендую к просмотру

на этом днище просто ничего нельзя сделать нормально

лол)

Чо лол? Это не смешно ни разу. Уж поверь поему 10 летнему опыту в пхп

со стороны

а есть принцип ООП, который звучит как "не делай лишних движений"?

YAGNI же

а уже написали

ну это все не ооп, это как-бы как RTFM

а я хотел может чего-то "ноучного"

а накидайте еще каких-то принципов, которые не входят с солид, но важны (ваше мнение)

- GRASP (кокберн, ларман и другие) - LoD - IoC (не помню кто...) - Information Hiding (Дэвид Парнас) - Single Chose Principle (Мэйерс) - Stable Dependencies Principle (дяди боба) - Abstract Dependencies Principle (дядя Боб) - Acyclic dependencies principle (дядя Боб)

- CQS мэйерса

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