Для чего нужны принципы SOLID?

SOLID принципы — фундамент качественного кода

SOLID — это набор из пяти принципов объектно-ориентированного проектирования, которые помогают создавать чистый, поддерживаемый и масштабируемый код. В Android разработке эти принципы критически важны для долгосрочной жизнеспособности приложения.

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

Классы должны иметь одну причину для изменения. Один класс — одна ответственность.

// ❌ Плохо: класс делает слишком много
class UserManager {
    fun loadUser(): User { /* сетевой запрос */ }
    fun saveUser(user: User) { /* сохранение в БД */ }
    fun displayUser(user: User) { /* обновление UI */ }
    fun sendAnalytics(event: String) { /* отправка аналитики */ }
}

// ✅ Хорошо: каждый класс со своей ответственностью
class UserRepository @Inject constructor(private val api: UserApi) {
    suspend fun loadUser(): User = api.getUser()
}

class UserViewModel @Inject constructor(
    private val repository: UserRepository
) : ViewModel() {
    val userLiveData: LiveData<User> = liveData {
        emit(repository.loadUser())
    }
}

O — Open/Closed Principle (Открыт для расширения, закрыт для модификации)

Нужно иметь возможность расширять функционал без изменения существующего кода.

// ❌ Плохо: нужно менять класс при добавлении нового способа логирования
class Logger {
    fun log(message: String) {
        if (type == "firebase") { /* Firebase */ }
        else if (type == "crashlytics") { /* Crashlytics */ }
    }
}

// ✅ Хорошо: используем интерфейсы для расширения
interface LoggingProvider {
    fun log(message: String)
}

class FirebaseLogger : LoggingProvider {
    override fun log(message: String) { /* Firebase */ }
}

class CrashlyticsLogger : LoggingProvider {
    override fun log(message: String) { /* Crashlytics */ }
}

class Logger @Inject constructor(
    private val provider: LoggingProvider
) {
    fun log(message: String) = provider.log(message)
}

L — Liskov Substitution Principle (Принцип подстановки Лискова)

Полиморфные объекты должны быть заменяемы без нарушения логики программы.

// ❌ Плохо: PremiumUser нарушает контракт User
abstract class User {
    open fun getDiscount(): Int = 0
}

class PremiumUser : User() {
    override fun getDiscount(): Int = 50
    fun getSpecialFeatures() { /* работает только для премиум */ }
}

// ✅ Хорошо: каждый подкласс соблюдает контракт
interface User {
    fun getDiscount(): Int
}

class FreeUser : User {
    override fun getDiscount(): Int = 0
}

class PremiumUser : User {
    override fun getDiscount(): Int = 50
}

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

Лучше иметь много специфичных интерфейсов, чем один универсальный.

// ❌ Плохо: слишком толстый интерфейс
interface DataSource {
    fun load(id: String): User
    fun save(user: User)
    fun delete(id: String)
    fun search(query: String): List<User>
    fun getStats(): Stats
}

// ✅ Хорошо: специфичные интерфейсы
interface ReadableDataSource {
    suspend fun load(id: String): User
    suspend fun search(query: String): List<User>
}

interface WritableDataSource {
    suspend fun save(user: User)
    suspend fun delete(id: String)
}

interface AnalyticsDataSource {
    suspend fun getStats(): Stats
}

D — Dependency Inversion Principle (Принцип инверсии зависимостей)

Зависи от абстракций, а не от конкретных реализаций.

// ❌ Плохо: прямая зависимость от конкретного класса
class UserViewModel : ViewModel() {
    private val repository = SqliteUserRepository()  // Жёсткая связь
}

// ✅ Хорошо: инъекция зависимости через интерфейс
class UserViewModel @Inject constructor(
    private val repository: UserRepository  // Зависимость от интерфейса
) : ViewModel() { }

Зачем нужны SOLID принципы в Android

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

• Тестируемость — легко писать unit тесты с mock объектами
• Поддерживаемость — код понятен и его легко менять
• Масштабируемость — легко добавлять новые функции
• Переиспользуемость — компоненты можно применять в разных местах
• Снижение связанности — слабая связь между компонентами
• Профилактика от багов — правильная архитектура предотвращает ошибки

Применение SOLID принципов требует больше времени на начальном этапе, но окупается многократно при поддержке и развитии приложения.