Что нарушает принцип разделения интерфейсов

Ответ на вопрос о нарушении принципа разделения интерфейсов (ISP)

Принцип разделения интерфейсов (Interface Segregation Principle, ISP) — один из пяти SOLID принципов объектно-оринтерованного проектирования, сформулированных Робертом Мартином. Его основная идея заключается в том, что клиенты не должны зависеть от методов, которые они не используют. Нарушение ISP происходит, когда интерфейс становится слишком «толстым» или «общим», вынуждая реализующие классы предоставлять пустые или нерелевантные реализации для некоторых методов. Это приводит к раздуванию кода, сложности поддержки и повышению связанности.

Типичные примеры нарушений ISP в коде

Рассмотрим классический пример с интерфейсом для устройств, имеющих многофункциональность:

// НАРУШЕНИЕ ISP: "толстый" интерфейс, объединяющий несвязанные возможности
interface MultiFunctionDevice {
    fun print(document: Document)
    fun scan(document: Document)
    fun fax(document: Document)
    fun copy(document: Document)
}

class BasicPrinter : MultiFunctionDevice {
    override fun print(document: Document) {
        // Реализация печати
    }
    
    override fun scan(document: Document) {
        throw UnsupportedOperationException("Сканнер не поддерживается!")
    }
    
    override fun fax(document: Document) {
        throw UnsupportedOperationException("Факс не поддерживается!")
    }
    
    override fun copy(document: Document) {
        throw UnsupportedOperationException("Копир не поддерживается!")
    }
}

В этом примере BasicPrinter вынужден реализовывать методы scan, fax и copy, хотя физически не обладает этими функциями. Это приводит к:

• Загромождению кода пустыми или исключающими реализациями.
• Нарушению инкапсуляции, так как класс раскрывает нерелевантные методы.
• Сложностям тестирования и повышенному риску ошибок времени выполнения.

Последствия нарушения ISP

1. Избыточные зависимости: Классы становятся зависимыми от интерфейсов, которые предлагают больше, чем нужно.
2. Хрупкость системы: Изменения в «толстом» интерфейсе затрагивают все реализации, даже если они не используют изменяемые методы.
3. Сложность повторного использования: Трудно выделить и использовать только нужную функциональность.
4. Нарушение принципа единственной ответственности (SRP): Интерфейс берет на себя несколько несвязанных ролей.

Решение через соблюдение ISP

Исправленный вариант разделяет интерфейс на специализированные:

// Соблюдение ISP: маленькие, сфокусированные интерфейсы
interface Printer {
    fun print(document: Document)
}

interface Scanner {
    fun scan(document: Document)
}

interface FaxMachine {
    fun fax(document: Document)
}

class BasicPrinter : Printer {
    override fun print(document: Document) {
        // Только необходимая реализация
    }
}

class MultiFunctionOfficeDevice : Printer, Scanner, FaxMachine {
    override fun print(document: Document) { /* реализация */ }
    override fun scan(document: Document) { /* реализация */ }
    override fun fax(document: Document) { /* реализация */ }
}

Признаки нарушения ISP в Android-разработке

1. Интерфейсы обратных вызовов (Listeners/Callbacks), которые объединяют множество несвязанных событий (например, OnUserInteractionListener с методами для кликов, свайпов и жестов).
2. Жирные интерфейсы в библиотеках или SDK, заставляющие реализовывать десятки методов, даже если нужны только 2-3.
3. Интерфейсы сервисов или репозиториев, которые смешивают операции для разных сущностей (например, DataManager с методами для работы с пользователями, товарами и заказами).

Практические рекомендации

• Разделяйте интерфейсы по ролям или клиентам: Каждый интерфейс должен обслуживать конкретного потребителя.
• Используйте дефолтные методы (в Java 8+) осторожно, чтобы не маскировать нарушение ISP.
• Применяйте принцип при проектировании API: Предоставляйте мелкие, композируемые интерфейсы.

Соблюдение ISP ведет к более гибкой, тестируемой и поддерживаемой архитектуре приложения, что особенно критично в долгосрочной разработке под Android, где требования часто меняются.