SB
Так нам жкзамен проводить кажому девелоперу на эти знания перед тем как к оду допускать?
Или заложить это в дизайн системы?
Чтобы язык контрлировал и типы за нас?
Или заложить это в дизайн системы?
Чтобы язык контрлировал и типы за нас?
Size: a a a
2021 May 05
M
Да как язык будет это контролировать, из той же ентити ты можешь куда хочешь обратиться
M
Если программисты не в состоянии это запомнить, то здесь уже, наверное, ничего поможет )
SB
как если конструктор закрыт и глобалочек нету?
M
Статические методы
SB
програмисты может и помнят
но обычно нам вот тут быстренько потом поправим на время...
но обычно нам вот тут быстренько потом поправим на время...
SB
глабалок по прeжнему нету значит статический метод тоже зависимостей иметь не может
Ну мол не вижу проблемы в создании типов Money::from() DateTime::from(). Мф же не зодим во вне мы внутри себя колупаемся
Ну мол не вижу проблемы в создании типов Money::from() DateTime::from(). Мф же не зодим во вне мы внутри себя колупаемся
M
Да и как конструктор закрыт, его же можно открыть
АГ
синглтоном пахнуло
SB
окей открыли конструктор для сущности
а толку?
Она же из базы полднимается там конструктор не используется
никакие зависмости не пролезут
я в этом плане
Контруктор работает только первый раз
далее сущность все больше не имеет права использовать оный
а толку?
Она же из базы полднимается там конструктор не используется
никакие зависмости не пролезут
я в этом плане
Контруктор работает только первый раз
далее сущность все больше не имеет права использовать оный
M
Ты можешь через метод передать зависимость
SB
Тут согласен
но по прежнему из вне полкчить доумп ко внутреностям ни кто не может
Сама сузность же контролирует какие хависимости так принять и что в них засунуть
Я это решаю тем что у сущности нельзя методы вызывать
Она только на сообщения (обычные структуры) реагирует
но по прежнему из вне полкчить доумп ко внутреностям ни кто не может
Сама сузность же контролирует какие хависимости так принять и что в них засунуть
Я это решаю тем что у сущности нельзя методы вызывать
Она только на сообщения (обычные структуры) реагирует
SP
Проблема в "размере энтити". Штуки типа "заказ" существуют между контекстами и как следствие ты будешь нарушать srp. Не потому что логика в сущностям и ты там дабл диспатчи юзаешь, а потому что у тебя одна штука знает и про платёжки и про доставку.
Если бы у тебя были сущности OrderPayment и OrderDelivery у которых из общего только айдишка - тут ещё можно про декомпозицию говорить.
Если бы у тебя были сущности OrderPayment и OrderDelivery у которых из общего только айдишка - тут ещё можно про декомпозицию говорить.
SP
Ну тоесть смысл в том что бы сущности были закрыты границами модулей. Что бы information hiding форсить, что бы управлять когнетивной сложностью
SP
Что бы в конечном итоге у тебя за разные куски могли разные люди отвечать и можно было бы с меньшим оверхэдом разработку скейлить
SP
Когда логика из сущностей "вытекает" и у тебя сеттеры и геттеры - это примерно тоже самое - если есть жирный order например. Просто в довесок мы ещё и потоки данных делаем неявными и хуй потом разберёшься кто кого дёргает и почему
M
Передавай в OrderPaymentService OrderPaymentData или OrderPaymentInterface
AK
OrderPaymentService не имплементит OrderPaymentInterface?
M
Нет, интерфейс может ентити имплементить, например
AK
а в чем разница между OrderPaymentService OrderPaymentData и OrderPaymentEntity?