Что такое принцип разделения интерфейса (Interface Segregation Principle)

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

Понимаете ли вы SOLID как набор практических правил, а не как список из учебника. По этому принципу легко проверить: попросят пример из вашего кода.

Как отвечать

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

Классический признак нарушения это реализация, где часть методов пустые или бросают исключение «не поддерживается». Лечится разделением на узкие интерфейсы по ролям, и класс реализует ровно те, что ему нужны:

interface Readable { fun read(id: String): Item }
interface Writable { fun save(item: Item) }

class ReadOnlyCache : Readable          // без пустых заглушек
class Repository : Readable, Writable

Что стоит добавить, чтобы ответ не звучал как пересказ:

• принцип про клиентов, а не про размер файла: интерфейс из десяти методов нормален, если все десять нужны каждому потребителю;
• дробление тоже имеет цену: пятнадцать интерфейсов по одному методу превращают код в мозаику. Ориентир это роли, а не методы поштучно;
• в Android это видно на слушателях: широкий колбэк вроде TextWatcher вынуждает реализовывать три метода ради одного, поэтому в котлине его оборачивают в узкую лямбду;
• связь с остальными принципами: узкие интерфейсы делают подстановку по Лискову честной, а инверсию зависимостей удобной, так как модуль зависит ровно от того, что использует.

Практическая польза в тестах: чтобы подменить зависимость, достаточно реализовать один метод, а не двенадцать.

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

Приводят пример с животными, которые не летают, и на этом останавливаются. Спросят про рабочий код, и ответить нечем.

Путают с принципом единственной ответственности: тот про причины изменения класса, этот про зависимость клиента от лишних методов.

Дробят интерфейсы до бессмысленных единиц, получая связанность через десяток мелких абстракций.