Ну так в конструкторе оно и с нулом. А дальше кто-то "опционально" может внедрить опциональную зависимость, если в процессе работы она кому-либо потребовалась.
_constructor(?Logger logger = null) this->logger = logger ?? new NullLogger
если мы делаем сервис потомок с одной дополнительной инъекцией логгера, например, то #[Required] сильно сократит код конструктор будет от родителя и потомку будет насрать на его возможные изменения
В таких случаях уж лучше декоратором сделать, не обращая внимания на "легко" или "тяжело", мне кажется.
_constructor(?Logger logger = null) this->logger = logger ?? new NullLogger
А скоро можно будет прям в объявлении писать
_constructor(?Logger logger = new NullLogger)
Так не спорю, я и говорил, что так делают. Но кроме этого ещё дают возможность в будущем указать другой логгер (если в конструктор сразу не добавили). Я не могу сказать, что это красиво, но и ужасным вряд ли назову.
Так не спорю, я и говорил, что так делают. Но кроме этого ещё дают возможность в будущем указать другой логгер (если в конструктор сразу не добавили). Я не могу сказать, что это красиво, но и ужасным вряд ли назову.
Ты указываешь интерфейс. А что там будет - всем похер, включая тебя
Если тебе в момент работы внезапно потребовалось поменять зависимость, то твое место в макдональдсе
Вот только это не "мне" может понадобиться, а кому-то/чему-то другому во время жизненного цикла аппки (но прыганье объекта туда сюда по проекту — тоже сомнительно)
Вот только это не "мне" может понадобиться, а кому-то/чему-то другому во время жизненного цикла аппки (но прыганье объекта туда сюда по проекту — тоже сомнительно)
Ты указываешь интерфейс. А что там будет - всем похер, включая тебя
А если объект передают дальше и потом нужно снять какую-то зависимость или заменить её? Следующий обработчик в цепочке может и не знать как декорацию снять. Нет?
А если объект передают дальше и потом нужно снять какую-то зависимость или заменить её? Следующий обработчик в цепочке может и не знать как декорацию снять. Нет?