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

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

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

В iOS это ежедневная практика: протоколы делегатов, абстракции над сетевым слоем, сервисы, которые подменяются в тестах. Жирный протокол виден сразу на тестовом двойнике, где ради одной проверки приходится заглушать десяток методов.

Как отвечать

Начните с формулировки: клиент не должен зависеть от методов, которые он не использует. Затем покажите разделение и композицию, в Swift она бесплатная.

protocol Printing { func printDoc(_ doc: Document) }
protocol Scanning { func scan() -> Document }

typealias Multifunction = Printing & Scanning

final class Reporter {
    private let printer: Printing // видит ровно то, что вызывает
    init(printer: Printing) { self.printer = printer }
}

Добавьте практическую пользу: узкие протоколы упрощают подмену в тестах, снимают ложные зависимости между модулями, а объект при необходимости реализует сразу несколько из них.

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

Дробят протоколы до одного метода и считают задачу решённой. ISP не про размер, а про потребности клиента: если вызывающему коду три метода нужны вместе, их место в одном протоколе, иначе получается россыпь абстракций, которую никто не может собрать обратно.

Затыкают лишние требования пустыми реализациями в extension или помечают методы как необязательные через совместимость с Objective-C. Компилятор замолкает, но клиент по-прежнему видит чужие методы, а вызов молча не делает ничего вместо честной ошибки сборки.

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