Может, лучше явно задачу описать?

Это понятно. У меня вопрос скорее был об реализации. DI в виде интерфейса куда проще мокается чем неведомая хрень с рефлексией под капотом

Интерфейс же не во всех случаях подходит

Читал её. И даже вот эту https://golangforall.com/ru/post/dependency-injection.html

А в каких не подходит? Мне кажется если не подходит интерфейс - то это ошибка скорее архитектуры

IMHO Constructor Injection и Parameter Injection (руками со сборкой в main) покрывают большинство юзкейсов. Контейнеры в целом не особо нужны, да они упрощают жизнь, но только на здоровенных монолитах, коих в Golang в общем то нет.

Ну в эту парадигму и сервис локатор укладывается. Один из вопросов как раз и был: почему он антипаттерн, а какая-то хрень с рефлексией - это типа гуд.

А как di связан с рефлексией?

Ты видимо про какую-то конкретную реализацию di контейнера пишешь?

Интерфейс эт что, это некая абстракция над разными по своей сути классами, что б объединить в что-то общее, но зачем это в юнит тестировании? Получается ты создаёшь абстракцию ради абстракции, а это еще один антипаттерн soft code 😁

Если ваши товарищи пишут что какая то одна реализация DI контейнера лучше другой, они скорее всего не достаточно глубоко разобрались в вопросе.

Где-то интерфейс подойдёт, но я б не назвал это уникальным способом

Как раз таки интерфейс изи мокается и в юнит-тестах go это как по мне самый паттерн

Я пришёл к такому же выводу. Спасибо

Дабы с ними не сраться, я бы предложил сесть командой, сделать табличку с разными реализациями и выписать все плюсы/минусы каждой.
И потом уже обсудить результаты того что получится.

Уже в конфлюенсе все выписал. Осталось похоливарить 😂

Имхо разница что одно уменьшает число сущностей, а второе наоборот

За счет чего уменьшается число сущностей? Я не вижу принципиальной разницы.

У меня интерфейс может соответствовать сразу и фабрике и хранилищем конфигов, логгеров и синглтонов... Более того инициализированные синглтоны не будут болтаться в глобальной области, что для GC гуд. И все это добро я могу замокать и сделать тестирование изи...

Скорее всего у меня непонимание православного DI и IoC которое все ж таки тащат за уши из других языков...

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

Ок. Интерфейс с реализацией в отдельном пакете(-ах),  некий метод конструктора реализации плюс фабричные методы...

За счёт того, что ты не создаёшь объект в каждом месте использования, а создаёшь только в одном

Плюс моки точно так же тянутся за уши, но никого это не смущает

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

Моки это не паттерн,  как их можно притягивать или не притягивать за уши, если это атрибут парадигмы юнит-тестирования?