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

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

IQ>>Можно делать всякое... я описал конкретный кейс который имхо наблюдается повсеместно, но почему-то мало критикуется или критикуется не по делу.
·>Ты описал кейс, но не предложил альтернативу. Как надо-то по-твоему?

Альтернатива простая — г...кодить г...код без DI.

IQ>>Гиперболизируя можно было бы добавить еще IJsonConverter чтобы механизм конвертирования json можно было изменить
·>А ты не подумал, что тот же JsonConverter может иметь ещё пять зависимостей, скажем настройки форматирования json и какие-нибудь там сериализаторы кастомных типов?
IQ>>и что ни будь вроде IDateTimeProvider, работа с датой и временем вряд ли поменяется, но
·>А мы так сделали в нашем проекте, ибо да, у нас "текущее время" оказалось вещью необычной.

Я привел имхо довольно понятную ситуацию, зачем вы мне описываете варианты где использование DI вполне уместно? Я же не говорю, что таких вообще не существует.

IQ>>на всякий случай стоит "уменьшить зависимости"
·>DI не уменьшает зависимости, а делает их явными.

Мы используем DI чтобы уменьшить/снизить зависимости — это не моя формулировка, это первое из обоснований наивного использования DI. Второе — DI позволит нам еще лучше писать юнит тесты.

·>Единственное что в твоём коде я бы поменял, так это выкинул все эти I* интерфейсы и инжектил бы сами классы. Интерфейс лежащий рядом с единственной имплементацией — не нужен.

Тогда пропадает видимость — IoC половина священной коровы.

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

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

IQ>>Можно делать всякое... я описал конкретный кейс который имхо наблюдается повсеместно, но почему-то мало критикуется или критикуется не по делу.
·>Ты описал кейс, но не предложил альтернативу. Как надо-то по-твоему?

Альтернатива простая — г...кодить г...код без DI.

IQ>>Гиперболизируя можно было бы добавить еще IJsonConverter чтобы механизм конвертирования json можно было изменить
·>А ты не подумал, что тот же JsonConverter может иметь ещё пять зависимостей, скажем настройки форматирования json и какие-нибудь там сериализаторы кастомных типов?
IQ>>и что ни будь вроде IDateTimeProvider, работа с датой и временем вряд ли поменяется, но
·>А мы так сделали в нашем проекте, ибо да, у нас "текущее время" оказалось вещью необычной.

Я привел имхо довольно понятную ситуацию, зачем вы мне описываете варианты где использование DI вполне уместно? Я же не говорю, что таких вообще не существует.

IQ>>на всякий случай стоит "уменьшить зависимости"
·>DI не уменьшает зависимости, а делает их явными.

Мы используем DI чтобы уменьшить/снизить зависимости — это не моя формулировка, это первое из обоснований наивного использования DI. Второе — DI позволит нам еще лучше писать юнит тесты.

·>Единственное что в твоём коде я бы поменял, так это выкинул все эти I* интерфейсы и инжектил бы сами классы. Интерфейс лежащий рядом с единственной имплементацией — не нужен.

Тогда пропадает видимость IoC — половина священной коровы.