Как делал Builder в Kotlin

Builder в Kotlin: краткий ответ

В Kotlin подход к паттерну Builder существенно отличается от классической Java-реализации. Благодаря встроенным языковым возможностям, полноценный GoF Builder часто избыточен. Вот основные подходы:

1. Именованные аргументы (Named Arguments)

Самый распространённый и идиоматичный способ — использование именованных аргументов с параметрами по умолчанию:

class Person(
    val name: String,
    val age: Int = 0,
    val address: String = "",
    val phone: String = ""
) {
    // Дополнительная логика класса
}

// Использование:
val person = Person(
    name = "Иван",
    age = 30,
    address = "Москва"
)
// Параметры можно пропускать благодаря значениям по умолчанию

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

• Лаконичный синтаксис
• Компилятор проверяет типы
• Невозможно создать частично инициализированный объект
• Иммутабельность по умолчанию

2. DSL-подход (Domain Specific Language)

Для сложных конфигураций можно создать DSL-строитель:

class CarBuilder {
    var model: String = ""
    var color: String = "Black"
    var horsepower: Int = 100
    
    fun build(): Car = Car(model, color, horsepower)
}

fun car(init: CarBuilder.() -> Unit): Car {
    val builder = CarBuilder()
    builder.init()
    return builder.build()
}

// Использование:
val myCar = car {
    model = "Tesla Model 3"
    color = "Red"
    horsepower = 350
}

3. apply() и also() для мутабельных объектов

Для конфигурации существующих объектов:

data class Configuration(
    var host: String = "",
    var port: Int = 8080,
    var timeout: Int = 5000
)

val config = Configuration().apply {
    host = "api.example.com"
    port = 443
    timeout = 10000
}

4. Классический Builder (для Java-взаимодействия)

Иногда необходим классический Builder, особенно для библиотек или фреймворков, ожидающих Java-стиль:

class Product private constructor(
    val id: String,
    val name: String,
    val price: Double
) {
    class Builder {
        private var id: String = ""
        private var name: String = ""
        private var price: Double = 0.0
        
        fun setId(id: String) = apply { this.id = id }
        fun setName(name: String) = apply { this.name = name }
        fun setPrice(price: Double) = apply { this.price = price }
        
        fun build() = Product(id, name, price)
    }
}

// Использование:
val product = Product.Builder()
    .setId("123")
    .setName("Laptop")
    .setPrice(999.99)
    .build()

5. @Builder аннотация Lombok (в Kotlin/Java проектах)

В смешанных проектах можно использовать Lombok:

import lombok.Builder

@Builder
data class User(
    val username: String,
    val email: String,
    val age: Int
)

// Генерирует builder автоматически

Критерии выбора подхода:

Когда использовать именованные аргументы:

• Большинство случаев в чистом Kotlin
• Относительно простая конфигурация
• Нужна иммутабельность
• Хочется минимального бойлерплейта

Когда использовать DSL-подход:

• Сложная конфигурация с множеством параметров
• Хочется fluent-интерфейс
• Нужна валидация параметров при построении
• Требуется читаемость для domain experts

Когда использовать классический Builder:

• Совместимость с Java-кодом
• Работа с библиотеками, ожидающими Builder-паттерн
• Постепенная миграция с Java на Kotlin

Ключевые выводы:

1. В Kotlin Builder часто антипаттерн — именованные аргументы с параметрами по умолчанию покрывают 90% случаев
2. Иммутабельность важна — большинство подходов в Kotlin сохраняют иммутабельность
3. Читаемость превыше всего — DSL и именованные аргументы делают код самодокументируемым
4. Минимизация boilerplate — Kotlin позволяет избежать избыточного кода строителей

Паттерн Builder в Kotlin трансформировался из обязательного шаблона проектирования в инструмент, который применяется осознанно только там, где действительно нужен, в то время как встроенные возможности языка покрывают большинство сценариев его использования в Java.