Что такое S в SOLID?

S в SOLID — Single Responsibility Principle (Принцип единственной ответственности)

S — первый и самый фундаментальный принцип из аббревиатуры SOLID. Он гласит: каждый класс должен иметь одну и только одну причину для изменения. Другими словами, класс должен быть ответственен только за одну задачу.

Суть принципа

Когда мы говорим о Single Responsibility, мы имеем в виду, что:

• Класс должен инкапсулировать одну область функциональности
• Класс не должен содержать несвязанную логику
• Если класс меняется, причина должна быть одна

Пример нарушения SRP

class User {
    fun getName(): String { }
    fun getEmail(): String { }
    
    // Логирование — это отдельная ответственность!
    fun logUserActivity() {
        println("User accessed: $getName")
    }
    
    // Сохранение в БД — это тоже отдельная ответственность!
    fun saveToDatabase() {
        // SQL запрос
    }
    
    // Отправка email — третья ответственность!
    fun sendNotification(message: String) {
        // SMTP логика
    }
}

Этот класс имеет три причины для изменения:

1. Изменение модели User
2. Изменение логики логирования
3. Изменение способа сохранения в БД
4. Изменение способа отправки уведомлений

Правильное применение SRP

// Класс только для данных пользователя
class User(val name: String, val email: String)

// Отдельный класс для работы с хранилищем
class UserRepository {
    fun save(user: User) {
        // SQL запрос
    }
}

// Отдельный класс для логирования
class UserLogger {
    fun logActivity(user: User) {
        println("User accessed: ${user.name}")
    }
}

// Отдельный класс для отправки уведомлений
class NotificationService {
    fun sendNotification(user: User, message: String) {
        // SMTP логика
    }
}

Преимущества SRP

• Тестируемость: Каждый класс легче тестировать изолированно
• Переиспользуемость: Классы с одной ответственностью легче переиспользовать в разных контекстах
• Гибкость: Изменения в одной части кода не влияют на другие
• Понятность: Код проще понять, когда каждый класс делает одно
• Поддерживаемость: Проще добавлять новые функции и исправлять баги

В контексте Android

На практике это выглядит так:

• ViewModel отвечает за управление состоянием UI
• Repository отвечает за получение данных
• UseCase отвечает за бизнес-логику
• Adapter отвечает только за отображение списка
• Service отвечает за фоновые операции

Single Responsibility Principle — это основа чистой архитектуры и делает код модульным, гибким и легко расширяемым.