Для чего надо делать DI в коде? Например, репозиторий передавать

в сервис через интерфейс, а не конкретный тип.

Существуют следующие варианты:
1. Тестирование. Чтобы реализацию репозитория заменить на мок. Ок. Это валидная причина, но она не главной должна быть.
2. Late Binding позднее связывание. Чтобы мы в рантайме могли выбрать конкретную реализацию репозитория, например mysql или postgres. В целом тоже валидная причина, но имхо довольно редкая.
3. Параллельная разработка. Репозиторий и сервис разрабатывается разными людьми одновременно. В целом тоже ок. Но опять вряд ли это главная причина
4. Расширяемость. Чтобы одну реализацию можно было заменить на другую. Хоть у меня и были такие ситуации, когда одна бд меняется на другую. Но все же это опять редкий случай. Но вот эта причина вроде, как главная. Она у Роберта Мартина вроде как основной считается. Но она все равно довольно редкая.

И вот разобрав эти причины в сухом остатке остается, что единственная не редкая причина для DIP - это именно тестирование. Есть мысли у кого-нибудь какие-то?

хм, передача интерфейса,, вместо реализации — это всё же IoC из SOLID

Ioc не из солид и не имеет к нему отношения. Dip из солида

точняк

DI у нас в тиме это ещё и удобная фабрика для инициализации всего этого добра

Вот тот же DIP - это довольно абстрактная штука. Я с ним согласен, но он скорее как эвристика, которая говорит: так делать хорошо. Но конкретную ситуацию бы подобрать, которая опишет почему так хорошо, не могу в данный момент

Ну вот у тебя репозитории пример. Консольная команда: "выведи список пакетов из репозитория": - interface IPackages и реализации - class GitHubPackages - class DatabasePackages

не зависеть от конкретной реализации

Вот неудовлетворительный ответ. Я всегда так и отвечал. Но что будет плохого, если у нас 1 репозиторий. В чем преимущество этой слабой связности? 1 импорт поменять в уровне сервиса? Ну не велика проблема

окей, если у тебя по определению несколько бд / адаптеров ?)

т.к. у тебя логотип "го" в имени, то есть пример очевиднее: Логгер))) Было бы неплохо завязываться на интерфейс логгера, например. Потому что реализаций куча, и одна хуже другой

Попробовал логгер убера — он говно. Одной кнопкой переключился на логгер другой (гугла например)

ну в основном один у меня

тут проблемы встают больше на больших кодовых базах

тут интерфейс ок т.к. все реализации именно разные. Но репозитории мы то делаем одинаковые. Одни и те же методы, одни и те же аргументы

а ты используешь в сервисе контейнер ?

Ну и у логгеров одни и теже методы будут. Один единственный log со строкой, уровнем "ошибки" (дебаг/варнинг/эррор/проч) и ещё что-то

вот видимо так и на маленьких кодовых базах кроме удовольствия от понимания, что у тебя "бизнес логика не зависит от деталей" реальная польза именно в возможности моки для тестов передавать

Что подразумеваешь под контейнером? Di контейнер? Я не использую

DIP не требуется для di. Просто не надо их вместе рассматривать. + Не всему нужны контейнера

ну авто рекваиринг

а я их и не сравнивал, di можно и без интерфейсов использовать

В дотнет мире (хотя там и есть DI и навязан) на примере репозитория ситуация следующая - обычно юзается какой то орм, и в сервисы передается дата-контекст. Через него уже получаем данные. Для тестирования можно (и на практике лучше) прям поднять тестовую базу и на ней гонять. При смене базы (если таковое случится) то меняется коннекшн стринг остальная работа нет. на самом деле конечно да, тк ни один орм не позволит совсем уж абстрагироваться от базы