Может кто-нибудь пояснить как именно реализуется принцип DIP на примере

приложения?Есть класс ViewModel и класс Repo(в который инжектится база данных и ретрофит).Repo в свою очередь инжектится в ViewModel. И Уже напрямую во ViewModel вызываются методы класса Repo,но это неправильно с точки зрения DIP,насколько я понимаю, так как это проектирование на уровне реализаций ,а не интерфейсов. Как сделать на уровне интерфейсов?

А почему неправильно? Ты инжектишь в реп дао (который интерфейс) и сервис ретрофита (тоже интерфейс). Во ViewModel ты инжектишь интерфейс репозитория, а какую именно его реализацию так это пусть di или сервис локатор решает

а у меня класс Repo не интерфейс ,а обычный класс

Так сделай интерфейс

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

Мартина читать начали?

да

на какой сейчас главе?

4

ваш вопрос разбирается на 5 главе (тольлько нужно не просто прочесть, а понять)

переделал схему Мартина, чтобы вам понятней было

как любезно, благодарю!

Наследовать модели репозитория(респонсы там всякие) от entity?

А почему нет?

Структура данных может отличаться

Ну как-то же она будет похожа. Она не будет прям вообще иной

В плане модели респонса к примеру могут не соответствовать домейн моделям, к примеру респонса три и они объединены а одну домейн модель

Это полная модель, для идеальных условий. Так то и интерфейс Presentatio мало кто пишет

Контекст такой: человек уже делает по клину, но не понимает как сделать/улучшить до каноничного клина

Понял, тогда со всем согласен

А мне вот лом интерфейс выделят для репозитория. Всегда делаю обычный класс. И вот такой вопрос не могу понять. Репозиторий - это абстракция для всего приложения/модуля? Или репозиторий - это абстракция для отдельной фитчи/интерактора/юзКеса?

Репозиторий это абстракция для конкретной сущности, а-ля UserRepository

Да! В этом и вопрос! Если у меня есть интерес UserRepository, и есть UserRepositoryImpl, который имплементирует единственный интерфейс UserRepository. Ведь я могу не делать интерфейс? В чём его польза а данном случае? Чем это может обернуться в будущем, если нужно будет что то менять?

Если пишешь на котлине, то замокать в тестах не сможешь обычным способом

Сложно тестировать, невозможно разделить слои приложения и вынести их в отдельные модули в случае потребности, нарушение SOLID

Это уже будет не clean architecture, так как domain слой будет знать про data слой

А какой именно аспект solid нарушается?

Да, теорию я знаю. Но в чём проблема на практике?

Ничем. Если одна имплементация и не нужны моки то интерфейс не нужен

Можно использовать mockk фреймворк

Предерживаюсь такого мнения. Хочу понять, на сколько это плохо?

И powermock. И ещё пачку всякого, что для тестов легаси. А можно просто писать по клину

Принцип инверсии зависимостей

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

А если класс одного модуля ссылается на конкретный класс другого? В чём проблема?

DI principle как раз гласит, что не нужно делать зависимости на что-то конкретное

Проблема переиспользования. Нельзя спокойно от отделить домен и репозиторий - нужно будет руками мержить. А если не собираетесь эту фичу в другой проект переносить - то технически и весь код в одной активити тоже ничего страшного не делает

Мокито давно уже умеет мокать финальные классы, достаточно прописать небольшой конфиг в тестовом res. А так согласен что для репозитория нужен интерфейс если фичи разбиты по модулям. А вот с интерактором у нас все проще это в 90% просто класс с бизнес логикой.

Прикольно, надо будет почитать на счет мокито тогда. Окей, тогда этот аргумент не самый удачный