SOLID принципы в Kotlin: продвинутое применение и практика

SOLID принципы в Kotlin: теория и практика на продвинутом уровне

SOLID — это фундаментальный набор принципов объектно-ориентированного проектирования, введённый Робертом Мартином. В контексте Kotlin, который сочетает в себе лучшие черты ООП и функционального программирования, эти принципы приобретают новые возможности для реализации. В этой статье мы рассмотрим каждый принцип на продвинутом уровне, используя уникальные возможности языка: инлайн-функции, делегирование, sealed-классы и extension-функции.

1. Single Responsibility Principle (SRP) и делегирование

Принцип единственной ответственности гласит: у класса должна быть только одна причина для изменения. В Kotlin для соблюдения SRP часто используется паттерн Делегирование (Delegation). Ключевое слово by позволяет автоматически делегировать реализацию интерфейса другому объекту.

Проблема: Класс UserService отвечает и за бизнес-логику, и за логирование, и за отправку email.

// ❌ Нарушение SRP
class UserService {
    fun registerUser(email: String, password: String) {
        // Бизнес-логика
        println("User registered")
        // Логирование
        log("User registered: $email")
        // Отправка email
        sendEmail(email, "Welcome!")
    }

    private fun log(message: String) { /* ... */ }
    private fun sendEmail(to: String, body: String) { /* ... */ }
}

Решение с использованием делегирования:

// ✅ Соблюдение SRP через делегирование
interface Logger {
    fun log(message: String)
}

interface EmailSender {
    fun send(to: String, body: String)
}

class ConsoleLogger : Logger {
    override fun log(message: String) = println("LOG: $message")
}

class SmtpEmailSender : EmailSender {
    override fun send(to: String, body: String) = println("Sending email to $to: $body")
}

class UserService(
    private val logger: Logger,
    private val emailSender: EmailSender
) : Logger by logger, EmailSender by emailSender { // 👈 Делегирование

    fun registerUser(email: String, password: String) {
        println("User registered")
        log("User registered: $email")
        send(email, "Welcome!")
    }
}

// Использование
fun main() {
    val service = UserService(ConsoleLogger(), SmtpEmailSender())
    service.registerUser("user@example.com", "pass123")
}

Использование by позволяет избежать шаблонного кода и чётко разделить обязанности. Класс UserService теперь отвечает только за регистрацию, а логирование и отправка делегированы отдельным классам.

2. Open-Closed Principle (OCP) и sealed-классы

Принцип открытости/закрытости: классы должны быть открыты для расширения, но закрыты для модификации. В Kotlin для этого идеально подходят sealed-классы и extension-функции.

Проблема: Функция processPayment использует when с проверкой типа, и при добавлении нового способа оплаты её приходится модифицировать.

// ❌ Нарушение OCP
fun processPayment(type: String, amount: Double) {
    when (type) {
        "card" -> println("Processing card payment: $amount")
        "paypal" -> println("Processing PayPal payment: $amount")
        else -> throw IllegalArgumentException("Unknown payment type")
    }
}

Решение с sealed-классами:

// ✅ Соблюдение OCP
sealed class PaymentMethod {
    data class Card(val number: String, val cvv: String) : PaymentMethod()
    data class PayPal(val email: String) : PaymentMethod()
    object Cash : PaymentMethod()
}

// Функция закрыта для модификации
fun processPayment(method: PaymentMethod, amount: Double) {
    // Когда появятся новые подклассы, компилятор потребует их обработки
    when (method) {
        is PaymentMethod.Card -> println("Processing card ${method.number}: $amount")
        is PaymentMethod.PayPal -> println("Processing PayPal ${method.email}: $amount")
        is PaymentMethod.Cash -> println("Processing cash: $amount")
    }
}

// Расширение через extension-функцию (без изменения sealed-класса)
fun PaymentMethod.isDigital(): Boolean = this !is PaymentMethod.Cash

fun main() {
    val payment = PaymentMethod.Card("1234-5678", "123")
    processPayment(payment, 100.0)
    println("Is digital? ${payment.isDigital()}")
}

Sealed-классы гарантируют, что при добавлении нового типа (например, PaymentMethod.Crypto) компилятор заставит вас обработать его во всех when-выражениях. Это делает код безопасным и расширяемым без модификации существующей логики.

3. Liskov Substitution Principle (LSP) и invariant-дженерики

Принцип подстановки Лисков: подклассы должны быть заменяемы своими базовыми классами без нарушения работы программы. В Kotlin на продвинутом уровне это тесно связано с вариантностью дженериков.

Проблема: Попытка использовать MutableList<Any> там, где ожидается List<String>.

// ❌ Нарушение LSP
fun printStrings(list: List<String>) {
    for (s in list) println(s)
}

fun main() {
    val mutableList: MutableList<Any> = mutableListOf(1, "two", 3.0)
    // printStrings(mutableList) // ❌ Ошибка компиляции
}

Правильное решение с использованием out (ковариантность):

// ✅ Соблюдение LSP через ковариантность
interface Source<out T> {
    fun fetch(): T
}

class StringSource : Source<String> {
    override fun fetch(): String = "Hello"
}

fun printFromSource(source: Source<Any>) {
    println(source.fetch())
}

fun main() {
    val stringSource = StringSource()
    printFromSource(stringSource) // ✅ Работает благодаря out
}

Ключевое слово out гарантирует, что Source<String> является подтипом Source<Any>. Это позволяет заменять один источник другим, соблюдая LSP. Для неизменяемых коллекций Kotlin (List, Set) используется именно такой подход.

4. Interface Segregation Principle (ISP) и inline-функции

Принцип разделения интерфейса: клиенты не должны зависеть от методов, которые они не используют. В Kotlin для этого часто применяются inline-функции и reified-типы.

Проблема: Большой интерфейс Worker заставляет реализовы