Изучая Dependency Injection

[Maksclub]

везде обсуждается КАК сделать, но практически нигде – ЗАЧЕМ

Мне казалось, что DI паттерн всегда объясняется со словом ЗАЧЕМ, всегда рядом есть такие аргументы как тестирование и принципы DIP (Dependency Inversion Principe) и OCP (Open/Closed Principe) из SOLID. Так как благодаря инверсии зависимостей мы можем использовать полиморфизм (тем самым облегчая подмену зависимости снаружи, чем и обеспечиваем оба принципа SOLID).

[IrixV]

Можно объяснять с точки зрения принципов, а можно — с точки зрения целей, это не совсем одно и тоже. Объяснять с точки зрения соблюдения принципов неплохо, потому что все принципы произошли из неких производственных необходимостей, и созданы для того, чтобы решать проблемы. Если человек это понимает — этого достаточно, если нет — начинаются споры о исполнение принципов ради самих принципов и т.п.

[Maksclub]

но помимо принципов я же указал: тестирование и использование полиморфизма для облегчения подмены реализации :--)

[Maksclub]

Кстати вчера задавали похожий вопрос на Тостере, мое объяснение «покороче» вашего вышло в силу специфики формата, так что в целом посту вашему плюс, разъяснять нужно это дело:
toster.ru/q/641030#answer_1406923

[KonstantinSpb]

Есть отличная книга по DI
www.amazon.com/Dependency-Injection-NET-Mark-Seemann/dp/1935182501

[rsi]

Замечение 1. Если, учитывая критику паттерна синглтон, вы решили заменить его, ну например, на UserDefaults, то применительно к данной ситуации, вырисовывается все та же неявная зависимость.

Странный пример. Хранение состояния в объекте(временном хранилище) и в UserDefaults(постоянном) совершенно разные вещи. Если человек может заменить одно на другое из архитектурных побуждений, ему рано заниматься архитектурой. Лучше почитать «Совершенный код».

… вырисовывается все та же неявная зависимость

Это верно только в том случае если использовать UserDefaults.standard, который тоже синглтон. Вы заменяете один синглтон на другой, конечно ничего в плане зависимостей не поменяется. Но UserDefaults тоже можно внедрять в класс, тогда все будет хорошо.

[s_suhanov]

Та и вообще многие разработчики до сих пор не могут понять, что синглтон — это не про зависимости, а про жизненный цикл. Синглтоны отлично оборачиваются протоколами, внедряются явными зависимостями и мокаются в юнит-тестах. Синглтон — это про хранение состояния всю жизнь приложения, а не про непредсказуемое поведение (ну если кодить нормально, конечно же). :)

[Shiny2]

fix