Что такое Interface segregation?

📌 Принцип разделения интерфейсов (Interface Segregation Principle, ISP)

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

🤔 Почему ISP важен в iOS-разработке?

В контексте iOS-разработки на Swift или Objective-C ISP помогает избежать типичных проблем:

1. Избегание «жирных» протоколов (Fat Protocols) – когда один протокол содержит десятки методов, и классы вынуждены реализовывать даже те, которые им не нужны (часто пустыми заглушками).
2. Уменьшение связанности (Coupling) – клиенты зависят только от того, что им действительно нужно.
3. Повышение читаемости и поддерживаемости – маленькие протоколы проще понимать и тестировать.

❌ Пример нарушения ISP

Представьте, что у вас есть протокол для работы с устройствами печати и сканирования в офисном приложении:

// ПЛОХО: "Жирный" протокол, нарушающий ISP
protocol OfficeMachine {
    func printDocument(_ document: String)
    func scanDocument() -> Data
    func faxDocument(_ document: String)
}

class ModernPrinter: OfficeMachine {
    func printDocument(_ document: String) {
        print("Печатаем: \(document)")
    }
    
    // Проблема: принтеру не нужно сканировать, но метод обязателен!
    func scanDocument() -> Data {
        fatalError("Этот принтер не умеет сканировать!")
    }
    
    // И не нужно отправлять факсы!
    func faxDocument(_ document: String) {
        fatalError("Факс не поддерживается!")
    }
}

Здесь класс ModernPrinter вынужден реализовывать методы scanDocument и faxDocument, хотя они ему не нужны. Это приводит к избыточному коду, нарушению логики и возможным крашам.

✅ Пример с применением ISP

Исправим ситуацию, разделив один большой протокол на несколько специализированных:

// ХОРОШО: Разделенные интерфейсы, соблюдаем ISP
protocol Printable {
    func printDocument(_ document: String)
}

protocol Scannable {
    func scanDocument() -> Data
}

protocol Faxable {
    func faxDocument(_ document: String)
}

// Теперь классы реализуют только нужные протоколы
class SimplePrinter: Printable {
    func printDocument(_ document: String) {
        print("Печатаем: \(document)")
    }
}

class AllInOnePrinter: Printable, Scannable {
    func printDocument(_ document: String) {
        print("Печатаем: \(document)")
    }
    
    func scanDocument() -> Data {
        print("Сканируем документ")
        return Data()
    }
}

🛠 Практическое применение в iOS

В iOS-разработке ISP особенно полезен в следующих сценариях:

1. Разделение делегатов (Delegates)

Вместо одного огромного делегата UITableViewDelegate (если бы он был одним протоколом со всеми методами) Apple разделила его на UITableViewDelegate и UITableViewDataSource. Вы можете подписаться только на нужные методы.

2. Протокол-ориентированные архитектуры

При использовании Protocol-Oriented Programming (POP) создавайте узкие протоколы:

// Пример для работы с сетью
protocol RequestSender {
    func sendRequest(_ request: URLRequest)
}

protocol ResponseParser {
    func parseResponse(_ data: Data) -> Decodable?
}

// Класс использует только нужные возможности
class NetworkService: RequestSender, ResponseParser {
    func sendRequest(_ request: URLRequest) { /* ... */ }
    func parseResponse(_ data: Data) -> Decodable? { /* ... */ }
}

3. Тестирование и моки

Маленькие протоколы проще мокировать в unit-тестах:

protocol UserDefaultsProtocol {
    func set(_ value: Any?, forKey key: String)
    func string(forKey key: String) -> String?
}

// В тестах создаем мок, реализующий только этот протокол
class UserDefaultsMock: UserDefaultsProtocol {
    var storage: [String: Any] = [:]
    
    func set(_ value: Any?, forKey key: String) {
        storage[key] = value
    }
    
    func string(forKey key: String) -> String? {
        return storage[key] as? String
    }
}

📊 Преимущества следования ISP

• Гибкость системы – проще добавлять новые функции, не затрагивая существующий код.
• Упрощение рефакторинга – изменения в одном интерфейсе затрагивают минимальное количество классов.
• Улучшение тестируемости – изолированные протоколы проще тестировать.
• Четкое разделение ответственности – каждый интерфейс отвечает за одну конкретную задачу.

🔄 Связь с другими принципами SOLID

ISP тесно связан с:

• Single Responsibility Principle (SRP) – ISP можно рассматривать как применение SRP к интерфейсам: один интерфейс — одна зона ответственности.
• Dependency Inversion Principle (DIP) – оба принципа поощряют зависимость от абстракций (протоколов), а не от конкретных реализаций.

💡 Вывод

Interface Segregation Principle — это мощный инструмент для создания гибких, поддерживаемых и тестируемых iOS-приложений. В мире Swift с его протокол-ориентированным дизайном следование ISP становится особенно естественным. Помните: лучше иметь много маленьких протоколов, чем один большой, который заставляет классы реализовывать ненужные методы. Это не только улучшает архитектуру, но и делает код более понятным для других разработчиков.