Когда нужно делить интерфейс на более мелкие части

Что проверяют

Обычно речь о принципе разделения интерфейсов (ISP, буква I в SOLID): видите ли вы признаки «толстого» контракта и умеете ли резать его без перегиба. Если формулировка кажется двусмысленной, уточните, про интерфейс в коде речь или про экран: следом могут спросить и про декомпозицию UI.

Как отвечать

Принцип: клиент не должен зависеть от методов, которые он не использует. Делить интерфейс пора, когда видны признаки:

• пустые реализации: классы реализуют методы пустым телом, TODO() или throw UnsupportedOperationException();
• разные клиенты: один экран только читает данные, другой только пишет, а зависят оба от общего UserRepository на двадцать методов;
• тесты: фейк для юнит-теста требует реализовать всё, хотя тест трогает один метод;
• лишние изменения: правка сигнатуры, нужной одному модулю, задевает всех остальных.

Хорошо работают примеры из самого Android. TextWatcher заставляет реализовать три метода ради одного afterTextChanged, поэтому в core-ktx есть doAfterTextChanged. У Animator.AnimatorListener четыре метода, и платформа добавила AnimatorListenerAdapter, чтобы не писать пустые заглушки.

Решение: резать по ролям клиентов (UserReader, UserWriter), а для одного метода объявлять fun interface, чтобы передавать лямбду. Один класс может реализовать несколько узких интерфейсов, а в Hilt каждый из них связывается с ним отдельным @Binds.

Если спрашивали про экран, логика та же: в отдельный composable выносят то, что переиспользуется или мешает читать. Состояние поднимают наверх (state hoisting), вниз передают данные и колбэки.

Где спотыкаются

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

Путают ISP с принципом единственной ответственности. SRP про причины менять класс, ISP про то, что видит конкретный клиент.

Прячут проблему за методами по умолчанию в Kotlin-интерфейсе. Заглушки просто переехали в сам интерфейс, а клиенты по-прежнему зависят от лишнего.