Кто может объяснить смысл дрочива с DI?

di == interface \thread

зочем оно тебе понадобилось?

Архитекторы задрачиывают

сочувствую))

лучше спросить в чате джавистов) они все подробно расскажут

Если говорить о практической пользе, то большой профит от di в юнит тестировании

Это про инжекцию зависимостей Типа если класс использует экземпляр другого класса то по принципам завешанным предками и лисковски надо создавать используемый объект вне использующего и внедрять в использующий, дабы не плодить лишних зависимостей В общем смысле это значит разделение использования и создания используемой сущности

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

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

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

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

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

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

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

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

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

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

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

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

За счет чего уменьшается число сущностей? Я не вижу принципиальной разницы. У меня интерфейс может соответствовать сразу и фабрике и хранилищем конфигов, логгеров и синглтонов... Более того инициализированные синглтоны не будут болтаться в глобальной области, что для GC гуд. И все это добро я могу замокать и сделать тестирование изи... Скорее всего у меня непонимание православного DI и IoC которое все ж таки тащат за уши из других языков... Из ключевого и обще-приемлемого я вынес, что в некоторой единой точке сборки должны быть собраны все провайдеры всех используемых сущностей, и раздаваться должны инжекторами, последовательно собирающих провайдерами некоторые выходные сущности... Ок. Интерфейс с реализацией в отдельном пакете(-ах), некий метод конструктора реализации плюс фабричные методы...

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

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

Тогда DI вам как бы и не нужно, у вас и так оно используется

)))) вот самое смешное я к тому же выводу пришел, единственное что я выпиливаю сейчас в легаси (а я пришел на проект, который исторически был на аутсерсе, когда-то) это растыканные сущности по другим объектам и переделываю передачу по параметру либо в методы, либо в конструкторы сущностей того что как общими усилиями выяснили и есть DI контейнер