Можешь привести пример использования принципа I в SOLID

Пример принципа Interface Segregation (ISP) в Android-разработке

Принцип Interface Segregation (ISP) — сегрегация (разделение) интерфейсов — гласит: "Клиенты не должны зависеть от интерфейсов, которые они не используют". На практике это означает, что вместо одного "толстого" интерфейса с множеством методов нужно создавать несколько специализированных, чтобы классы реализовывали только то, что им действительно нужно.

Проблема: нарушение ISP ("жирный" интерфейс)

Рассмотрим типичную проблему в Android-приложении. Допустим, у нас есть интерфейс MediaPlayer для работы с медиа-контентом:

// НАРУШЕНИЕ ISP: Интерфейс заставляет реализовывать ненужные методы
interface MediaPlayer {
    fun playAudio(audioFile: String)
    fun pauseAudio()
    fun stopAudio()
    
    fun playVideo(videoFile: String) // Метод, нужный только видеоплееру
    fun pauseVideo()                  // Метод, нужный только видеоплееру
    fun stopVideo()                   // Метод, нужный только видеоплееру
    
    fun displaySubtitles(subtitleFile: String) // Метод, нужный только видеоплееру
}

Теперь создадим класс AudioPlayer, который должен только воспроизводить аудио:

class AudioPlayer : MediaPlayer {
    override fun playAudio(audioFile: String) {
        // Реализация воспроизведения аудио
    }
    
    override fun pauseAudio() {
        // Пауза аудио
    }
    
    override fun stopAudio() {
        // Остановка аудио
    }
    
    // ПРОБЛЕМА: AudioPlayer вынужден реализовывать ненужные методы!
    override fun playVideo(videoFile: String) {
        throw UnsupportedOperationException("AudioPlayer не поддерживает видео")
    }
    
    override fun pauseVideo() {
        throw UnsupportedOperationException("AudioPlayer не поддерживает видео")
    }
    
    override fun stopVideo() {
        throw UnsupportedOperationException("AudioPlayer не поддерживает видео")
    }
    
    override fun displaySubtitles(subtitleFile: String) {
        throw UnsupportedOperationException("AudioPlayer не поддерживает субтитры")
    }
}

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

• Избыточность кода: класс содержит методы, которые никогда не будут использоваться
• Нарушение принципа единой ответственности: класс знает о функциональности, которая ему не принадлежит
• Сложность поддержки: при изменении видеоплеера придется менять и аудиоплеер
• Ошибки времени выполнения: вместо ошибок компиляции получаем исключения в runtime

Решение: применение Interface Segregation

Разделим "толстый" интерфейс на несколько специализированных:

// Интерфейс только для аудио-функциональности
interface AudioPlayer {
    fun playAudio(audioFile: String)
    fun pauseAudio()
    fun stopAudio()
}

// Интерфейс только для видео-функциональности
interface VideoPlayer {
    fun playVideo(videoFile: String)
    fun pauseVideo()
    fun stopVideo()
}

// Интерфейс для дополнительной видео-функциональности
interface SubtitleSupport {
    fun displaySubtitles(subtitleFile: String)
    fun hideSubtitles()
}

Теперь классы реализуют только необходимые интерфейсы:

// Аудиоплеер реализует ТОЛЬКО аудио-интерфейс
class SimpleAudioPlayer : AudioPlayer {
    override fun playAudio(audioFile: String) {
        // Реализация воспроизведения аудио
    }
    
    override fun pauseAudio() {
        // Пауза аудио
    }
    
    override fun stopAudio() {
        // Остановка аудио
    }
}

// Видеоплеер реализует несколько интерфейсов - только то, что нужно
class AdvancedVideoPlayer : VideoPlayer, SubtitleSupport {
    override fun playVideo(videoFile: String) {
        // Реализация воспроизведения видео
    }
    
    override fun pauseVideo() {
        // Пауза видео
    }
    
    override fun stopVideo() {
        // Остановка видео
    }
    
    override fun displaySubtitles(subtitleFile: String) {
        // Показать субтитры
    }
    
    override fun hideSubtitles() {
        // Скрыть субтитры
    }
}

// Медиаплеер, поддерживающий всё
class UniversalMediaPlayer : AudioPlayer, VideoPlayer, SubtitleSupport {
    // Реализация всех методов
}

Реальный пример из Android-разработки

В Android SDK принцип ISP применяется очень грамотно. Рассмотрим работу с сенсорами:

// Вместо одного интерфейса со всеми типами сенсоров используются отдельные слушатели
interface SensorEventListener {
    // Проблема: если нужно только отслеживать изменения, аккураситет не нужен
    fun onSensorChanged(event: SensorEvent)
    fun onAccuracyChanged(sensor: Sensor, accuracy: Int)
}

// Решение по ISP: разделение на отдельные интерфейсы могло бы выглядеть так:
interface SensorChangeListener {
    fun onSensorChanged(event: SensorEvent)
}

interface SensorAccuracyListener {
    fun onAccuracyChanged(sensor: Sensor, accuracy: Int)
}

Преимущества применения ISP в Android

1. Уменьшение связности: классы зависят только от необходимой функциональности
2. Упрощение тестирования: моки и стабы создаются только для используемых интерфейсов
3. Безопасность рефакторинга: изменения в видеоплеере не затрагивают аудиоплеер
4. Читаемость кода: сразу видно, какую функциональность предоставляет класс
5. Соблюдение Single Responsibility: каждый интерфейс имеет одну четкую цель

Практическое применение в архитектуре Android

В современных подходах к Android-архитектуре ISP проявляется особенно ярко:

// Вместо одного "Repository" со всеми методами
interface UserRepository {
    fun getLocalUser(): User
    fun getRemoteUser(): User
    fun saveUser(user: User)
    fun deleteUser(user: User)
    fun getProducts(): List<Product> // Метод, не относящийся к пользователям!
}

// Применяем ISP:
interface UserLocalDataSource {
    fun getLocalUser(): User
    fun saveUser(user: User)
}

interface UserRemoteDataSource {
    fun getRemoteUser(): User
}

interface ProductRepository {
    fun getProducts(): List<Product>
}

// Класс использует только нужные интерфейсы
class UserRepositoryImpl(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) {
    // Реализация только пользовательской логики
}

Заключение: Принцип Interface Segregation в Android-разработке помогает создавать гибкие, поддерживаемые и тестируемые приложения. Он особенно важен при работе с библиотеками, фреймворками и в крупных проектах, где четкое разделение ответственности между компонентами критически важно для долгосрочной поддержки кодовой базы. Правильное применение ISP уменьшает количество неиспользуемого кода, предотвращает непреднамеренные breaking changes и способствует созданию чистых архитектурных решений.