Деконструкція: val (a, b) і _

1. Деконструкція Pair і Triple

Якщо ви тільки починаєте програмувати, доступ через first/second здається нормальним: «ну є ж поля — то й беру». Але доволі швидко код перетворюється на маленький квест: де first — це x, а де first — це min, а де first — це «повідомлення про помилку»? Деконструкція розвʼязує це просто: ви одразу даєте компонентам нормальні імена, і далі код читається як звичайний текст.

Друга причина — локальна читабельність. Коли ви «розгортаєте» Pair у x і y, вам більше не потрібно тримати в голові, що означало first. Змінні стають самодокументованими. І це той рідкісний випадок, коли компілятор не лише свариться, а й допомагає писати зрозуміліший код.

Pair: val (a, b) = pair

Найпоширеніший варіант — розпакувати Pair у дві змінні. Синтаксис виглядає так, ніби ми «присвоюємо одразу дві змінні», хоча технічно це все ще один вираз праворуч і одне оголошення ліворуч.

Почнімо з максимально простого прикладу:

fun main() {
    val point = 10 to 20

    val (x, y) = point
    println("x=$x y=$y") // x=10 y=20
}

Зверніть увагу на два моменти. По‑перше, ліворуч ми оголосили дві змінні x і y. По‑друге, сенс first/second тепер «закладений» в імена: x — це перше, y — це друге, і читач коду не зобовʼязаний памʼятати, що там десь лежить Pair.

Деконструкція проти first/second: коли що зручніше

Іноді логіка така: ви використовуєте обидві частини — тоді деконструкція зазвичай виграє. Якщо ж вам потрібна лише одна частина, інколи простіше взяти pair.first або pair.second. Щоб не сперечатися, можна мислити так: деконструкція добра, коли ви потім багато разів використовуєте компоненти окремо, а first/second зручні, коли ви берете один компонент один раз і відразу його застосовуєте.

Порівняймо на прикладі:

fun main() {
    val range = 1 to 100

    // Варіант A: без деконструкції
    println("from=" + range.first)  // from=1
    println("to=" + range.second)   // to=100

    // Варіант B: з деконструкцією
    val (from, to) = range
    println("from=$from to=$to")    // from=1 to=100
}

Обидва варіанти коректні. Але в другому випадку «домовленість» про сенс компонентів винесена в імена from/to, і це зазвичай зменшує шанс переплутати порядок.

Чи можна вказувати типи під час деконструкції?

Так, можна. Зазвичай Kotlin сам виводить типи, але інколи корисно зробити тип явним, щоб ви самі розуміли, що відбувається (або щоб компілятор підказав помилку раніше).

fun main() {
    val data: Pair<Int, String> = 7 to "days"

    val (count: Int, label: String) = data
    println("$count $label") // 7 days
}

На практиці частіше достатньо val (count, label) = data, але можливість явно вказати тип — хороший «план Б», якщо є сумніви.

Triple: val (a, b, c) = triple

Triple — це те саме, тільки на три компоненти. І деконструкція тут особливо приємна, бо first/second/third читаються ще важче, ніж first/second: мозок починає сприймати їх як «перше/друге/третє щось», а не як конкретні значення.

Приклад з RGB-кольором:

fun main() {
    val rgb = Triple(255, 128, 0)

    val (r, g, b) = rgb
    println("r=$r g=$g b=$b") // r=255 g=128 b=0
}

Тут деконструкція не просто «коротша», вона робить головне: ми прибрали слова first/second/third і замінили їх на терміни предметної області (r/g/b). Це рівно те, за що деконструкцію люблять у реальному коді.

2. Пропуск компонентів через _

Тепер важливий прийом: іноді Pair або Triple потрібен вам як контейнер «щоб перенести все разом», але в конкретному місці використання потрібна лише частина. Заводити змінну лише для того, щоб вона лежала мертвим вантажем, не хочеться — і компілятор теж не хоче: він почне попереджати, що змінна не використовується.

Для цього в Kotlin є _ у деконструкції: це означає «цей компонент мені не потрібен». Це не змінна, а саме заглушка.

Приклад:

fun main() {
    val result = "OK" to 200

    val (status, _) = result
    println(status) // OK
}

Другий компонент (200) ми пропустили. І це читається як навмисне рішення: «я знаю, що там є код, але зараз він мені не потрібен».

_ не можна використовувати як змінну

Дуже часта початкова помилка: спробувати потім звернутися до _, ніби це імʼя змінної. Це не спрацює.

fun main() {
    val p = 3 to 4
    val (_, y) = p

    println(y)   // 4
    println(_) // так не можна: "_" не змінна
}

Така суворість — лише плюс: вона захищає від випадкового використання того, що ви самі оголосили як «неважливе».

_ корисний ще й як підказка читачеві

Іноді в новачків зʼявляється думка: «а що поганого в val (a, b), якщо b не потрібен?» Поганого нічого, програма працюватиме, але читачеві коду (зокрема й вам за тиждень) буде незрозуміло: компонент справді важливий, просто поки не використовується, чи він узагалі зайвий? _ розвʼязує це чесно: «ні, він не потрібен».

3. Як працює деконструкція: componentN()

Розберімося, як усе це працює — ми ж програмісти. Деконструкція виглядає як особливий синтаксис мови, але насправді компілятор просто перетворює її на виклики спеціальних функцій componentN().

Правило просте: якщо обʼєкт уміє відповідати на component1(), component2() (тощо), то його можна деконструювати. У специфікації Kotlin прямо показано, що деконструкція спирається на ці component‑функції, і розкладання йде за порядком компонентів.

Приклад: вручну замість деконструкції

Те, що компілятор робить автоматично, ми можемо написати й самі:

fun main() {
    val p = 3 to 4

    val a = p.component1()
    val b = p.component2()

    println(a + b) // 7
}

Це не «краще», ніж val (a, b) = p, але корисно побачити механіку. Деконструкція — це зручне пакування навколо component‑викликів.

Міні-схема того, що відбувається

Якщо спростити, то деконструкція:

val (a, b) = pair

приблизно еквівалентна такій ідеї:

tmp = pair
a = tmp.component1()
b = tmp.component2()

І важлива деталь: створюється тимчасова змінна tmp, щоб вираз праворуч обчислювався один раз. Це особливо помітно на вкладеній деконструкції (коли «всередині» теж Pair), і специфікація ілюструє, як компілятор розкладає це в послідовність componentN() з тимчасовими змінними.

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

Обмеження: деконструкція — це оголошення, а не присвоювання

У Kotlin деконструкція в такому вигляді працює саме як оголошення нових змінних:

val (x, y) = point

Але не як «перезаписати вже наявні x і y одним рядком». Тобто ви не можете зробити «деконструктивне присвоювання» у стилі Python — тут доведеться присвоювати окремо або переоголошувати змінні в новій області видимості (наприклад, усередині блока { ... }).

4. Практика: «ContactCard» на Pair

Давайте акуратно вбудуємо деконструкцію в наш навчальний проєкт «пишемо маленькі функції й друкуємо результат». Уявімо, що ми робимо просту консольну заготовку «картки контакту»: імʼя і телефон. Поки без складної архітектури й без команд — просто показуємо ідею.

Створімо Pair як «контакт» і гарно розпакуємо:

fun main() {
    val contact = "Ada Lovelace" to "+44 123 456"

    val (name, phone) = contact
    println("Імʼя: $name")   // Імʼя: Ada Lovelace
    println("Телефон: $phone") // Телефон: +44 123 456
}

Тепер зробімо варіант, де телефон не потрібен (наприклад, ми виводимо лише імʼя для списку):

fun main() {
    val contact = "Ada Lovelace" to "+44 123 456"

    val (name, _) = contact
    println("Імʼя: $name") // Імʼя: Ada Lovelace
}

Зауважте, наскільки це зручно читати: ви прямо показуєте намір — взяти лише імʼя.

5. Типові помилки під час деконструкції Pair/Triple

Помилка № 1: намагатися деконструювати Pair у три змінні (або Triple у дві).
Це одна з найчастіших «помилок форми»: ліворуч три імені, праворуч обʼєкт із двома компонентами. Компілятор не вгадує ваших думок і чесно скаже, що бракує component3() або, навпаки, ви просите замало компонентів. У голові варто тримати просту відповідність: Pair — це рівно два компоненти, Triple — рівно три.

Помилка № 2: використовувати беззмістовні імена a, b, c там, де важливий сенс.
Сама по собі деконструкція не робить код автоматично зрозумілим: вона лише дає шанс добре назвати речі. Якщо ви пишете val (a, b) = range, то читач усе одно гадатиме, що таке a і b. Якщо це межі діапазону — хай буде from/to, якщо це координати — x/y, якщо це статус і код — status/code.

Помилка № 3: деконструювати заради деконструкції, коли потрібен один компонент.
Іноді люди пишуть val (x, _) = pair навіть тоді, коли простіше й зрозуміліше взяти pair.first. Формально це нормально, але за стилем зазвичай виграє той варіант, який менше «рухає код». Якщо потрібен один компонент один раз — беріть first/second/third. Якщо потім компоненти активно живуть у коді — деконструюйте.

Помилка № 4: забути, що порядок компонентів — це контракт.
Деконструкція розкладає строго за порядком: перше в першу змінну, друге в другу тощо. Вона не «розуміє», що ви хотіли. Тому якщо в одному місці ви вирішили, що minMax — це (min, max), дотримуйтеся цього всюди. Інакше ви отримаєте баг, який виглядає як «усе працює, але чомусь іноді відʼємні числа стають додатними».

Помилка № 5: сприймати _ як звичайну змінну.
_ у деконструкції — це саме «викинути компонент», а не «назвати змінну підкресленням». Його не можна вивести println(_), передати далі, зберегти тощо. Якщо ви раптом зрозуміли, що компонент усе-таки потрібен — просто дайте йому нормальне імʼя.

Помилка № 6: не розуміти звʼязок із componentN() і лякатися повідомлень компілятора.
Іноді компілятор свариться на відсутність component2() або несумісність типів — і це звучить як закляття з темної магії. Але за цим стоїть проста механіка: деконструкція = виклики componentN() за порядком. Якщо памʼятати цей звʼязок, повідомлення компілятора стають зрозумілими: «не можу дістати другий компонент» або «другий компонент не того типу».