Здравствуйте, vmpire, Вы писали:

V>Здравствуйте, ·, Вы писали:

V>>>Тут по сути возможны всего две ошибки: попытка использования незарегистрированного объекта и попытка использовать объект с меньшим временем жизни, чем использующий.
V>>>Обе они вылетают сразу в момент создания использующего объектаэ
V>·>Верно. А в нормальном wiring коде такие ошибки просто подсвечиваются красным как ошибка компиляции ещё в процессе набора кода.
V>Это просто баланс интересов. Минимальное дублирование кода и отделение логики создания объектов ценой потенциальных ошибок в рантайме.

V>>>Тот пример, который Вы привели выше (императивная связь объектов) ведёт к дублированию кода
V>·>Ты всё ещё не проникся. Wiring код это самый обыкновенный код, который пишется ровно так же как и весь остальной код. Скажем, дублирование можно избежать выносом одинаковых кусков в переиспользуемый метод или, например, оборачиванием в какой-нибудь цикл.
V>·>Если ты умеешь избегать дублирование кода в принципе, то это же умение точно так же работает и для wiring-кода.
V>Я как раз проникся. Как только мы в этом wiring коде отделяем логику создания объектов с целью его переиспользования от логики их связи, мы как раз и получаем самый обыкновенный DI контейнер, разве что статический.
Точнее, контейнером станет набор переменных, в которых лежат созданные объекты перед тем, как их связали.
V>С семи же потенциальными проблемами рантайма(забыли создать объект, который потом пытаемся связать).
V>Тут, правда, поможет новая фишка C# про nullable reference types, но только в не очень сложных случаях.

V>>>и неудобен, когда нужно закодировать разное время жизни объектов и при этом создавать их по требованию.
V>·>Эээ... Фабрика/билдер?
V>Ну и напишете вручную тот же код, который уже есть в DI фреймворке. И в чём тогда плюсы?

Здравствуйте, vmpire, Вы писали:

V>Здравствуйте, ·, Вы писали:

V>>>Тут по сути возможны всего две ошибки: попытка использования незарегистрированного объекта и попытка использовать объект с меньшим временем жизни, чем использующий.
V>>>Обе они вылетают сразу в момент создания использующего объектаэ
V>·>Верно. А в нормальном wiring коде такие ошибки просто подсвечиваются красным как ошибка компиляции ещё в процессе набора кода.
Это просто баланс интересов. Минимальное дублирование кода и отделение логики создания объектов ценой потенциальных ошибок в рантайме.

V>>>Тот пример, который Вы привели выше (императивная связь объектов) ведёт к дублированию кода
V>·>Ты всё ещё не проникся. Wiring код это самый обыкновенный код, который пишется ровно так же как и весь остальной код. Скажем, дублирование можно избежать выносом одинаковых кусков в переиспользуемый метод или, например, оборачиванием в какой-нибудь цикл.
V>·>Если ты умеешь избегать дублирование кода в принципе, то это же умение точно так же работает и для wiring-кода.
Я как раз проникся. Как только мы в этом wiring коде отделяем логику создания объектов с целью его переиспользования от логики их связи, мы как раз и получаем самый обыкновенный DI контейнер, разве что статический.
Точнее, контейнером станет набор переменных, в которых лежат созданные объекты перед тем, как их связали.
С семи же потенциальными проблемами рантайма(забыли создать объект, который потом пытаемся связать).
Тут, правда, поможет новая фишка C# про nullable reference types, но только в не очень сложных случаях.

V>>>и неудобен, когда нужно закодировать разное время жизни объектов и при этом создавать их по требованию.
V>·>Эээ... Фабрика/билдер?
Ну и напишете вручную тот же код, который уже есть в DI фреймворке. И в чём тогда плюсы?