они даже обоснованы
Когда был джуном сам часто кидался всякими умными статьями
Но на практике надо писать максимально просто
То есть сделай сначала базовое ветвление, отделив данные, логику приложения и View
На этом этапе у тебя получилось MVVM, где на уровне View - Activity/Fragment, на уровне логики приложения ViewModel, которая хранит состояние, на уровне Model - Retrofit Service, Room Dao
Важно, что пока ничего покрывать интерфейсом не надо! Это только путает
Идём дальше, нам понадобилось кешировать данные. Например, у нас такая логика: получаем данные из БД, показываем эти данные, грузим из сети, сохраняем в БД, показываем из БД
Появилась логика получения данных
Отлично, значит мы можем заюзать Repository и работать через него
Нам нужно всё приложение покрывать тестами? Хорошо, а какие конкретно объекты мы будем заменять на моки? Repository? Значит его покроем интерфейсом. Если не будем писать юнит тесты, значит оставляем Repository в виде object
Приложение не просто тонкий клиент, а ещё и хранит много бизнес-логики? Значит добавляем Interactor
В приложении есть необходимость постоянно менять реализацию хранения БД? Например, вместо Room использовать GreenDao? Значит можно заюзать DataSource
Или заюзать DataSource, когда есть очень много логики в Repository. Например, ты реализуешь пагинацию
И так далее. В общем принцип такой, что нужно максимально упрощать код, не забывая про здравый смысл
ну я просто заранее хочу быть готовым поэтому скейлю, легче опять же тестить, мокать, одним движением заменять и ничего не давит на нервную систему. Согласен, нужно находить баланс и ставить деплой в приоритет
Получилось добавить Provides?
я еще не билдил пока
Виталий, а мне же для этого надо будет все модули сделать абстрактными классами, а не объектами и у моих функций не будет реализаций
По поводу реализаций не понял Но если хочешь юзать Binds, то нужно использовать абстрактный класс или интерфейс
Обсуждают сегодня