Understanding Dependency Injection

[gonosq]

В настоящий момент изучаю сами знаете какой супергероический фреймворк))

Концептуально непонятно одна вещь: зачем нужно внедрение зависимостей?

Конечно сейчас кто-то упал со стула от моей вопиющей невежественности, но тем не менее. Из всего что я успел прочитать, DI упоминается чаще всего в связке с сервисами.

Например мне нужно использовать в моём контроллере некий самописный сервис myserv. Чтобы иметь его в списке аргументов функции инициализации контроллера я выполняю некий ритуал описанный в офф. доке и прочих разных мануалах, туториалах и статьях. Этот ритуал для меня ещё несколько мутноват отчасти как-раз из-за того, что непонятна конечная цель.

Итак, пусть мой сервис myserv настраивает что-то на сервере используя xhr (ajax). Вместо использования DI я вполне могу объявить window.services и разместить в нём все необходимые мне сервисы, в том числе и myserv.
Это единственная вещь, которую я должен сделать дополнительно к написанию самого сервиса, т.к. она позволит избежать конфликта имён в глобальной области видимости. Почему я должен делать что-то ещё?

Что могло бы обосновать использования DI:
1. Ленивая подгрузка сервисов. А она есть в angular?
2. Встроенные сервисы не будут доступны в коде новых сервисов если не оформить их как положен))
3. Я вообще всё не так понял

И пожалуй всё. Больше не вижу причин.

Буду признателен если уже использующие angular прояснили эти моменты, а то вкуривать во всякие магические ритуалы не видя цели очень скушно))

[nerv_]

3. Я вообще всё не так понял

//

[gonosq]

Просьба к понимающим правильно: поясните.

Если абстрагироваться от языка и фреймворка.
Я понимаю, например, когда один модуль зависит от других, менеджер зависимостей может подтянуть недостающие на этапе сборки или исполнения.

А что происходит в angular?

[gonosq]

Что могло бы обосновать использования DI:
1. Ленивая подгрузка сервисов. А она есть в angular?
2. Встроенные сервисы не будут доступны в коде новых сервисов если не оформить их как положен))
3. Я вообще всё не так понял

4. Возможность делать заглушки для сервисов при юнит тестировани (это первая, более или менее весомая причина)

[gonosq]

4. Возможность делать заглушки для сервисов при юнит тестировани (это первая, более или менее весомая причина)

5. Улучшается переносимость модулей.
5.1 Все зависимости перечислены при объявлении модуля и не надо выискивать их в коде
5.2 Возможны альтернативные реализации зависимостей при соблюдении интерфейса работы с ними (по сути так-же как с юнит тестами)

Использовать ли DI для своих сервисов, для меня пока вопрос открытый, а они у меня будут и много.
Как говорит нам википедия: "С другой стороны, излишнее использование внедрения зависимостей может сделать приложения более сложными и трудными в сопровождении ...". И я с этим абсолютно согласен.

В общем, я на свой вопрос ответил. Кто имеет что добавить - пишите.