Приведи пример разделения интерфейсов

Пример разделения интерфейсов (Interface Segregation Principle)

Принцип разделения интерфейсов (Interface Segregation Principle, ISP) — один из пяти принципов SOLID. Он утверждает, что клиенты не должны зависеть от интерфейсов, которые они не используют. Вместо одного большого общего интерфейса лучше создать несколько специализированных, чтобы классы реализовывали только те методы, которые им действительно нужны.

Проблема: нарушение ISP

Рассмотрим интерфейс Worker, который описывает все возможные действия сотрудника в компании. Это приводит к тому, что классы, реализующие этот интерфейс, должны предоставлять пустые реализации для неиспользуемых методов.

// Плохой пример: слишком "тяжелый" интерфейс
protocol Worker {
    func work()
    func eat()
    func attendMeeting()
    func code()
    func design()
    func test()
}

class Developer: Worker {
    func work() { print("Разработчик работает") }
    func eat() { print("Разработчик ест") }
    func attendMeeting() { print("Разработчик на встрече") }
    func code() { print("Разработчик пишет код") }
    func design() { print("Разработчик делает дизайн") } // Не используется!
    func test() { print("Разработчик проводит тесты") } // Не используется!
}

class Designer: Worker {
    func work() { print("Дизайнер работает") }
    func eat() { print("Дизайнер ест") }
    func attendMeeting() { print("Дизайнер на встрече") }
    func code() { print("Дизайнер пишет код") } // Не используется!
    func design() { print("Дизайнер делает дизайн") }
    func test() { print("Дизайнер проводит тесты") } // Не используется!
}

Проблемы такого подхода:

• Классы содержат пустые или нерелевантные реализации (например, Developer.design()).
• Изменение интерфейса (например, добавление нового метода) затрагивает все классы, даже те, которые его не используют.
• Снижается читаемость и поддерживаемость — интерфейс становится слишком абстрактным и неясным.

Решение: применение ISP

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

// Хороший пример: разделенные интерфейсы
protocol Employee {
    func work()
    func eat()
    func attendMeeting()
}

protocol DeveloperTasks {
    func code()
    func test()
}

protocol DesignerTasks {
    func design()
}

class Developer: Employee, DeveloperTasks {
    func work() { print("Разработчик работает") }
    func eat() { print("Разработчик ест") }
    func attendMeeting() { print("Разработчик на встрече") }
    func code() { print("Разработчик пишет код") }
    func test() { print("Разработчик проводит тесты") }
}

class Designer: Employee, DesignerTasks {
    func work() { print("Дизайнер работает") }
    func eat() { print("Дизайнер ест") }
    func attendMeeting() { print("Дизайнер на встрече") }
    func design() { print("Дизайнер делает дизайн") }
}

Преимущества такого разделения

• Уменьшение зависимости: Классы зависят только от необходимых им интерфейсов. Developer не знает о методах дизайна, Designer не знает о методах разработки.
• Улучшение поддерживаемости: Добавление новой функциональности (например, интерфейса ManagerTasks) не требует изменений в существующих классах Developer или Designer.
• Повышение гибкости: Легко создавать новые роли (например, HybridEmployee, реализующий Employee, DeveloperTasks и DesignerTasks) без нарушения существующей структуры.
• Более чистая архитектура: Интерфейсы становятся сфокусированными и самодостаточными, что улучшает понимание системы.

Практическое применение ISP в iOS разработке

В iOS разработке ISP особенно важен при создании модульных компонентов, таких как сервисы, делегаты или DataSource.

// Пример: разделение делегата UITableView
// Вместо одного массивного делегата, UIKit использует разделенные протоколы
protocol UITableViewDataSource {
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell
}

protocol UITableViewDelegate {
    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath)
    func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat
}

// Класс может реализовать только нужный ему протокол
class MyViewController: UIViewController, UITableViewDataSource {
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return items.count
    }
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        return UITableViewCell()
    }
    // Не реализуем UITableViewDelegate, если не нужны обработка выделения или кастомная высота строк
}

Вывод

Применение принципа разделения интерфейсов позволяет создавать более декомпозированные, гибкие и устойчивые к изменениям системы. Вместо создания "интерфейсов-богомолов", которые пытаются охватить всё, мы проектируем специализированные контракты, строго соответствующие конкретным ролям или задачам в приложении. Это напрямую влияет на снижение связности и упрощение тестирования, что является критически важным для долгосрочной поддержки iOS приложения.