lateinit — відкладена ініціалізація та безпечний дизайн API класу

1. Навіщо потрібен lateinit

Іноді обʼєкт потрібно створити одразу, а дані для нього зʼявляться лише пізніше — за сценарієм роботи програми. Наприклад, ви пишете консольний застосунок: користувач запускає програму, вона створює «ядро» застосунку, а потім ставить запитання: імʼя, валюта, режим роботи тощо. З погляду коду виходить така ситуація: обʼєкт уже існує, але частина важливих полів зʼявиться тільки після діалогу з користувачем. І хочеться, щоб ці поля були non-null, бо «якщо валюту не задано — застосунок просто не має сенсу».

Типова дилема новачка виглядає так: або зробити поле nullable (String?) і потім усюди писати перевірки, або дати якесь «тимчасове» значення на кшталт "UNKNOWN", а тоді сподіватися, що ви не забудете замінити його на справжнє. І саме тут Kotlin пропонує інструмент, що звучить як чарівне заклинання зі школи Гоґвортсу: lateinit.

Проблема: обʼєкт уже створено, а даних іще немає

Уявіть, що ви купили чайник (обʼєкт створено), але воду ще не налили (властивість не готова). Чайник без води — це нормально, але вмикати його не можна. А хороший дизайн API має не допустити «увімкнення порожнього чайника».

lateinit як контракт «ініціалізують пізніше»

Важливо вловити головну думку ще до того, як рука потягнеться ліпити lateinit у кожен клас «про всяк випадок». lateinit — це не спосіб «обдурити Kotlin», а спосіб явно зафіксувати контракт: «цю властивість обовʼязково буде задано, але не в момент створення обʼєкта». Тобто ви не робите поле nullable — ви кажете: «воно буде non-null, але трохи пізніше».

Коли ви використовуєте lateinit, ви оголошуєте властивість var без ініціалізації, але водночас обіцяєте, що встановите її пізніше (зазвичай — окремим методом або зовнішньою логікою, яка точно виконується). Kotlin це дозволяє, але відповідальність за порядок дій перекладається на вас.

class Config {
    lateinit var apiKey: String
}

Тут apiKey — не nullable (String, не String?), але під час створення Config() її ще не задано. Пізніше ви зробите config.apiKey = "...".

Обмеження lateinit

Із lateinit повʼязано кілька обмежень. Вони зʼявилися не «через шкідливість компілятора», а тому що інакше поведінка стала б надто «магічною» й небезпечною.

lateinit можна використовувати лише якщо:

lateinit var name: String

lateinit var list: MutableList<String>

lateinit val token: String

lateinit var count: Int

lateinit var x: String?

Те, що lateinit не працює для Int, часто дивує. Але якщо замислитися, тут усе логічно: Kotlin не може «зберігати відсутність значення» всередині Int без якогось спеціального маркера. Для посилань є природний маркер «немає значення» — це null, а для Int такого «порожнього стану» немає (принаймні на рівні Kotlin-контракту).

Чому для lateinit майже завжди потрібен явний тип

У вас не буде значення праворуч, отже Kotlin не зможе вивести тип за ініціалізацією. Тому тип потрібно вказати явно. Це той самий принцип, який ми вже бачили для змінних без початкового значення.

Порівняйте:

val x = 10          // тип виведеться сам
val y: Int          // без ініціалізації тип обовʼязковий

З lateinit та сама ідея — просто всередині класу:

class Session {
    lateinit var currency: String
}

Що буде, якщо звернутися до lateinit надто рано

lateinit — це не «мʼяка» конструкція. Вона дуже чесна: якщо ви порушили контракт (прочитали властивість до присвоювання), програма падає з помилкою часу виконання. І, власне, це хороша новина: помилка виникає одразу, а не перетворюється на тихе пошкодження даних.

Подивімося, як це виглядає в мініприкладі. Тут я навмисно роблю неправильно, щоб ви побачили симптом.

class Profile {
    lateinit var userName: String
}

fun main() {
    val p = Profile()

    // Ми забули p.userName = "..."
    println(p.userName) // Бум
}

У реальному житті це зазвичай проявляється як виняток «property ... has not been initialized». Якщо ви почнете «лікувати» це через try/catch, то просто замаскуєте баг: застосунок продовжить працювати в некоректному стані. Тому нормальна стратегія — не «ловити падіння», а спроєктувати API так, щоб падіння не траплялося.

2. Безпечний дизайн API з lateinit

Коли зʼявляється lateinit, майже завжди виникає й друге запитання: «Як зробити так, щоб ніхто (зокрема й я сам за тиждень) не зміг викликати методи в неправильному порядку?» Це і є дизайн API. Ми хочемо, щоб використання обʼєкта виглядало як зрозумілий сценарій: спочатку підготували, потім працюємо. А якщо сценарій порушено — отримуємо швидке «падіння» (fail-fast) із хорошим текстом.

Тут нам особливо допомагають require(...) і check(...): перший — про коректність вхідних даних, другий — про коректність стану обʼєкта.

Шаблон: init(...) + check(...)

Суть шаблону проста: ви зберігаєте lateinit усередині, а назовні даєте метод init(...), який переводить обʼєкт у «готовий» стан. Усі методи, яким потрібна готовність, починаються з внутрішньої перевірки check(...).

class AnalyticsClient {
    private var ready: Boolean = false
    lateinit var apiKey: String
        private set

    fun init(key: String) {
        require(key.isNotBlank()) { "apiKey не має бути порожнім" }
        apiKey = key
        ready = true
    }

    fun send(event: String) {
        check(ready) { "AnalyticsClient не ініціалізовано. Спочатку викличте init(...)." }
        println("Надіслати '$event' з apiKey=$apiKey")
    }
}

Зверніть увагу: ми не даємо ззовні присвоювати apiKey (у нього private set), тож ініціалізація відбувається через init(...). А check(...) — це явний охоронець біля дверей, який не пускає вас у методи завчасно.

Чому lateinit краще ховати всередині класу

Дуже поширена помилка новачків: зробити public lateinit var і потім присвоювати його звідки завгодно. Це зручно рівно одну хвилину — поки проєкт маленький. А далі ви або випадково записуєте туди щось не те, або забуваєте присвоїти значення, або присвоюєте двічі — і починається веселий квест «чому воно падає».

Намагайтеся мислити так: lateinit — це внутрішня деталь, а не «кнопка для всіх». Тому найчастіше він має бути private або хоча б із private set, а назовні мають бути методи, які гарантують коректність сценарію.

require(...) і check(...): хто за що відповідає

Тут легко заплутатися, тож проговорімо це людською мовою.

• require(...) використовується, коли користувач (або код, що викликає) передав вам неправильний аргумент: порожній рядок, відʼємне число, непідтримуваний формат. Це «помилка введення».
• check(...) використовується, коли аргументи нормальні, але обʼєкт зараз у невідповідному стані. Наприклад, ви не викликали init(...), але намагаєтеся send(...). Це «помилка сценарію/логіки».

І так, ці перевірки — не «злість на користувача», а спосіб зробити код передбачуваним. Зрештою, компʼютер і так усе зламає — питання лише в тому, де саме.

3. Практичний приклад: консольний трекер витрат BudgetBuddy

Щоб lateinit не залишився «абстрактною штукою з підручника», давайте вбудуємо його в невеликий фрагмент консольного застосунку. Уявімо, що ми робимо простого помічника для обліку витрат: користувач запускає програму, вводить імʼя та валюту, а потім додає витрати. Імʼя та валюта мають бути обовʼязковими, але зʼявляються лише після старту й діалогу.

Ми зробимо клас BudgetBuddySession: він створюється одразу, але стає придатним до роботи лише після init(...).

Модель витрати Expense

Почнімо з дуже простої моделі витрати. Вона потрібна, щоб було що зберігати в списку й друкувати. Тут жодних фокусів: дані та трохи зручності для виводу.

data class Expense(
    val title: String,
    val amountCents: Int
) {
    init {
        require(title.isNotBlank()) { "title не має бути порожнім" }
        require(amountCents > 0) { "amountCents має бути > 0" }
    }
}

require(...) тут — про коректність вхідних даних під час створення обʼєкта: витрата з порожньою назвою та сумою 0 — підозріла, як «знижка 100 %» у магазині.

BudgetBuddySession: lateinit для даних, що зʼявляться після старту

Тепер сама «сесія». У ній будуть імʼя користувача, валюта та список витрат. Імʼя й валюта — обовʼязкові, але задаються пізніше, тому робимо їх lateinit. Водночас запис ззовні ми закриваємо.

class BudgetBuddySession {
    private var ready: Boolean = false

    lateinit var userName: String
        private set

    lateinit var currency: String
        private set

    private val expenses = mutableListOf<Expense>()

    fun init(userName: String, currency: String) {
        require(userName.isNotBlank()) { "userName не має бути порожнім" }
        require(currency.isNotBlank()) { "currency не має бути порожнім" }

        this.userName = userName.trim()
        this.currency = currency.trim().uppercase()
        ready = true
    }
}

Зауважте: ми використовуємо trim() і uppercase() прямо в init(...), щоб стан усередині обʼєкта був нормалізованим. Це зменшує шанс, що десь потім ви будете порівнювати "usd" і "USD" та дивуватися, чому вони не рівні.

Методи, які потребують готовності

Наступний крок — дати сесії операції: додати витрату й надрукувати список. І тут важливий прийом: не розмазувати перевірки по всьому класу, а зробити невеликий приватний метод ensureReady() і викликати його там, де потрібно.

class BudgetBuddySession {
    private var ready: Boolean = false

    lateinit var userName: String
        private set
    lateinit var currency: String
        private set

    private val expenses = mutableListOf<Expense>()

    fun init(userName: String, currency: String) {
        require(userName.isNotBlank()) { "userName не має бути порожнім" }
        require(currency.isNotBlank()) { "currency не має бути порожнім" }

        this.userName = userName.trim()
        this.currency = currency.trim().uppercase()
        ready = true
    }

    private fun ensureReady() {
        check(ready) { "Сесію не ініціалізовано. Спочатку викличте init(...)." }
    }

    fun addExpense(title: String, amountCents: Int) {
        ensureReady()
        expenses.add(Expense(title, amountCents))
    }

    fun printAll() {
        ensureReady()
        println("Витрати $userName ($currency):")
        expenses.forEach { println("- ${it.title}: ${it.amountCents} центів") }
    }
}

Тут check(...) — це саме перевірка стану. Якщо ви забули викликати init(...), обʼєкт іще «не готовий», і методи чесно вам про це повідомляють.

Використання в main

Тепер зберімо маленький сценарій. Ми створюємо сесію, запитуємо в користувача імʼя та валюту, викликаємо init(...), а потім користуємося методами.

fun main() {
    val session = BudgetBuddySession()

    print("Ваше імʼя: ")
    val name = readln().trim()

    print("Валюта (наприклад, USD): ")
    val currency = readln().trim()

    session.init(name, currency)

    session.addExpense("Coffee", 450)
    session.addExpense("Sandwich", 899)

    session.printAll()
    // Витрати Alice (USD):
    // - Coffee: 450 центів
    // - Sandwich: 899 центів
}

Ззовні це виглядає як нормальний контракт: спочатку ініціалізація, потім робота. Ми не даємо випадково зробити session.currency = "LOL" посеред програми — у властивості private set.

4. Коли lateinit доречний

Є небезпечний момент: щойно ви дізналися про lateinit, мозок починає бачити в ньому універсальний ключ від усіх дверей. Але lateinit — не універсальний ключ. Радше це запасний вхід, яким користуються, коли головний зачинений з обʼєктивних причин.

Головне правило таке: якщо значення обовʼязкове і відоме на момент створення, передавайте його через конструктор. Якщо значення може бути відсутнім за змістом, використовуйте nullable-тип. Якщо ж значення обовʼязкове, але зʼявляється пізніше за сценарієм, тоді lateinit — кандидат.

Невелика табличка-навігатор:

Зауважте, що про lazy я сказав рівно стільки, скільки потрібно, щоб не плутати його з lateinit: це не «присвоїмо пізніше», а «обчислимо пізніше». Детально розберемо це в наступній лекції.

5. Типові помилки під час роботи з lateinit

Помилка №1: використовувати lateinit, «щоб не думати».
Найчастіша причина появи lateinit у неправильних місцях — бажання уникнути вибору між конструктором і nullable. Але lateinit не прибирає потреби думати: він лише переносить відповідальність на порядок викликів. Якщо значення завжди має бути відоме під час створення обʼєкта, набагато чистіше передати його в primary constructor і не влаштовувати обʼєкту «підлітковий період», коли він існує, але ще не розуміє, хто він у житті.

Помилка №2: робити public lateinit var і дозволяти присвоювання звідки завгодно.
Так ви втрачаєте контроль над станом: хтось присвоїв, хтось перезаписав, хтось забув, хтось присвоїв порожній рядок. lateinit майже завжди має бути прихованим: private або хоча б із private set. А зовнішній світ має спілкуватися з обʼєктом через методи на кшталт init(...), де ви можете нормалізувати й провалідовувати дані.

Помилка №3: перевіряти готовність «де доведеться» замість одного явного контракту.
Іноді код перетворюється на клаптикову ковдру: в одному методі перевірка є, в іншому — забули, у третьому — зробили іншу перевірку. У підсумку обʼєкт поводиться непередбачувано. Значно надійніше мати одну точку контролю: або приватний ensureReady() із check(...), або суворе правило, що публічні методи доступні лише після init(...).

Помилка №4: намагатися «лікувати» проблему через try/catch і продовжувати роботу.
Якщо ви прочитали lateinit-властивість до ініціалізації — це не «очікувана помилка введення», це зламаний сценарій. Ловити виняток і продовжувати — майже завжди означає: «ми зараз підемо далі в некоректному стані й зламаємо щось іще, але вже в іншому місці». Для таких ситуацій правильніше fail-fast: check(...) зі зрозумілим повідомленням.

Помилка №5: змішувати require(...) і check(...) та отримувати дивні повідомлення.
Коли користувач увів порожнє імʼя — це аргумент, і тут доречніше require(...). Коли ви забули викликати init(...) і полізли в addExpense(...) — це стан, і тут доречніше check(...). Якщо переплутати, повідомлення про помилки вводитимуть в оману: ви будете «лаяти користувача» за те, що це ви пропустили крок ініціалізації (або навпаки).