дело в удобстве если твой пет проект и хочешь вм ниже в класс окна засунуть, сам решай, если уж делать один стиль то делать во всем проекте так, когда вм маленькая ладно, а если логика появится в какой нибудь вм то будет портянка, по мне так намного приятнее выглядит когда так: - ui - screens - news - list NewsAdapter NewsHolder NewsFragment NewsViewModel на работе будет стандарт, и там уже как скажут так и будешь делать)
Прочитай, что такое интерфейс 😏
бля, я не так прочел :D сорян
А по пакетам я почти так же бью, только фича->presentation->
а по поводу твоего вопроса, интерфейс предполагает расширение, и если в дальнейшем у тебя появятся новые реализации то ты в один файл все будешь кидать?
Логично, но есть специфические интерфейсы, которые применяются только в одном классе
По поводу разбиение по пакетам, все-же изначально лучше бить по фичам а не слоям)
Вообще интерфейс предполагает неоднократную реализацию.
не только. может еще быть неудовлетворённая на данном уровне связности зависимость которую ты отгораживаешь интерфейсом
Например?
да самое простое интерфейсы датасорсов в домене "хочу вот такой метод чтоб получить такую то фигню из репозитория, вот контракт" (ну окей да в виде контракта), реализация будет где то в другом модуле, но это не значит что надо выбросить интерфейс из за единственной реализации
кмк интерфейсы и датасорсы - это отдельная песня
окей, роутинг тоже отдельная песня? "хочу вот такие переходы на другие экраны", и реализация в модуле app
Обсуждают сегодня