да, достижения "каноничного" представления чистой архитектуры не хватает переноса интерфейсов репо. Но это не даст ничего кроме независимости домена, который при отсутствии переиспользования бизнес-логики в иных проектах или иных источников данных для разных версий проекта - ноль толка имеет. На мой взгляд в представленном проекте больше внимания стоит уделить принципам солида, дизайнам классов и предметной области. Интерактор в текущем варианте обслуживает активити. А что если отображение списка песен потребуется ещё на каком-нибудь фрагменте или активити? Придется или дублировать или делать фасад, а за этим ещё большее расширение проекта станет причиной появления большего количества фасадов -> круговые зависимости -> головная боль и проблемы или повальное дублирование и изменения во многих классах. Вряд-ли предметной областью приложения является предоставление и обслуживание активити. То же относится и к репозиторию. Но это только мой скромный взгляд 😌
спасибо конечно, но там между интерактором и активити есть еще и презентер, если надо переиспользовать, то флаг в руки.
Обсуждают сегодня