все оборачивают в интерфейсы. Объясните, в чем смысл этого?
ну это наверное исходя из тестирования, чтобы потом создать отдельную реализацию например для тестов
Не скажу, что всё оборачиваю, но мне просто нравится иметь некий контракт для классов. Открыл интерфейс и сразу видишь, что его реализация умеет делать. Там же стараюсь вести основную java-доку.
Ну, во-первых: вообще всё оборачивать не имеет смысла. Во-вторых: общую логику всё же лучше оборачивать. Для вью и презентера всё понятно. Про интерактор и репозиторий (он же gateway) я часто слышал, что лучше для них не писать интерфейсы, но с этим я категорически не согласен. Как я предлагаю делать: для каждого экрана описывать свой контракт с внутренними интерфейсами View Presenter Interactor Gateway, где описывать только те методы, которые нужны этим Interactor и Gateway, а потом все интерфейсы Interactor-ов имплементить реальным интеракторам (которые не по одному для каждого экрана, а по фичам). Итого, какой профит: 1) программирование на уровне интерфейсов 2) слабая связанность 3) изоляция не нужного функционала
кроме упрощенного тестирования, гибкость в изменении реализаций. Но во всем должна быть мера. Все оборачивать в интерфейсы - это конечно избыточно
Обсуждают сегодня