Нужна помощь по clean+многомодульность. с DI как быть? DI в

каждую фичу добавлять или отдельный модуль юзать для DI?

У кого есть хорошая практика, чтобы по граблям не ходить, дайте совет

Nick

😂😂😂

Nick

в самое сердце бьёшь

У тебя сколько проектов одновременно? Ты прям из одной крайности в другую прыгаеш

Nick

Ну я же писал, если 30 модулей это норма. Если 1000 это ад. Ты короче меня запомнил на всю оставшуюся жизнь я смотрю))

фриланс дело сложное)

Кому как )

Ну да, просто бывают такие проекты, что приходиться подстраиваться под них, иначе денушку не получишь)

пусть проекты под тебя подстраиваются

Представь что у тебя каждая фича это aar который ты цепляшь к проекту через implement. В этом случае как ты сам на вопрос ответишь?

Тут заказчик нервный)) не получается

Опять же. А нужен ли DI?

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

да нужен.

Щяс без DI разве clean где - то пишут? я не видел такого

Я тоже пару месяцев назад задавался этим вопросом. Таки пишут. А ещё di ломает solid

понятно, а как тестят?

А кто не даёт все зависимости через конструктор провайдить?) Слои абсолютно не меняются

А как di ломает solid?

Самый банальный пример - есть интерфейс, есть две реализации, тебе нужно дать понять библиотеке, какую ты будешь реализацию пробрасывать. В даггере ты будешь использовать какой-то @Named или другой кволифаер, на зависимом конструкторе. Считай, ты неявно подарил прямую зависимость - ты не сможешь сюда дать другую реализацию

Вот тут как раз этот пример детально смотрят https://www.pragmaticobjects.com/chapters/007_di_containers.html

Спасибо, почитаю

ну эт проблема контейнера такие штуки можно в модуле спрятать

Да, спринг даёт возможность, например, выносить это в XML. Только и он кривой и все используют аннотации. В статье, что я скинул, есть размышления и на эту тему. Не могу сказать, что мне нравиться идея самому писать код для группирования "матрёшек" с логикой, но di - не серебряная пуля

На счёт прятать в модуле, предлагаешь сделать provide-метод, который будет получать named интерфейс и возвращать, как обычный?

Провайдив через конструктор ты тоже используешь DI.

Не обязательно, я могу руками туда сложить всё

Зачем? Смысл di теряется

class A(val dep: Dependency) fun main() { val dep = DependencyImpl() val a = A(dep) } Это всё ещё DI. Ты предоставляешь зависимости из вне.

Так о том и соль, что жить можно по клину и без di

Ну можно, удачи. Можно и не юзать ретрофит с окхттп)

DI - это ещё и в поля инъекции, и в методы, да. Не верно выражаюсь наверное, можно писать по клину без di-библиотек

Так, не, давай по делу. Di-либы ломают солид, а писать самопальные штуки - это другое

да, вариант

Думал о чем-то подобном раньше, это не будет работать. Ты запросил конкретную реализацию, снял с нее эту пометку "конкретная реализация А" и отправил дальше. Опять же, не выйдет теперь другую реализацию подсунуть. Условно говоря, проблему под ковер запрятать, подальше от глаз

ну прям можно подумать что DI чисто для ретрофита замутили. как бы до DI ретрофит (и подобное) в синглтон загоняли и не парились... Опять же с точки зрения кода в маленьких проектах нафиг DI не нужен, если у тебя реально только один ретрофит + 2-3 фрагмента

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

велосипеды - это святое ) их трогать низя

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

Кстати, прикольно

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

У нас в продакшн как раз такой подход и используется. DI-фреймворки слишком расслабляют и разрабы начинают их использовать направо и налево, без разбору, ломая структуру. Использование стандартных средств ООП, без монстрофреймворков, создает более строгую, SOLIDную и более простую структуру кода. Да и компилится такой проект быстрее.

https://hmp3.ru/07zCVbZnG1MqDFWhYBX7hg_sergey-kapralov-di-containers-vs-objects.html Вот тут на русском.

Простите можно подробней. Как именно они ломают солид?)

Вот тут был пример. Штука именно в реализации, а не в принципе. Опять же, немного выше по сообщениям от этого момента есть пример, как обойти такое, это да

Сори, возможно что-то упускаю, но почему бы в примере из статьи не заинжектить фабрику, которая уже в рантайме будет решать какую из реализаций бинов отдавать?

Тоже вариант. В тестах мокать лишнее придется, а так - да. Ну и еще мое субьективное - хочется не фабрики везде носить за собой, а реальные зависимости)