Лекції

Розбираємося, як у Kotlin працює підтипність в узагальнених типах: чому List<Expense> можна безпечно використовувати як List<Transaction>, але MutableList<Expense> не можна «підняти» до MutableList<Transaction>. На прикладах показуємо інваріантність контейнерів ( Box<T>), коваріантність read-only колекцій, помилки компілятора та практичні прийоми проєктування API (приймати List, якщо не потрібно мутувати), а також інтуїцію на прикладі типів функцій (Transaction) -> String.

Розбираємо declaration-site variance у Kotlin: як оголошувати коваріантні producer-типи через out і контраваріантні consumer-типи через in, чому компілятор забороняє небезпечні операції (наприклад, var із параметром типу) та як це повʼязано зі звичними типами на кшталт List, Comparable і функціональними типами (A) -> B. Наприкінці — прикладний рефакторинг (джерело звіту + принтер) і перелік типових помилок проєктування.

Розбираємося, чому Array<T> у Kotlin інваріантний, чим небезпечні приведення через as і як use-site variance (проєкції типів) «урізає» API посилання до безпечного режиму: out для читання (producer) і in для запису (consumer). Закріплюємо це на прикладах копіювання масивів і контрактів для MutableList — зокрема на практичному сценарії з фінансовими операціями.

Розбираємо star-projection * у Kotlin на прикладі List<*> і MutableList<*>. Зʼясуємо, що на практиці означає «невідомий тип», чому під час читання елементи мають тип Any?, а запис у MutableList<*> заборонено (логіка на кшталт in Nothing). Також розглянемо, як застосовувати перевірки is List<*> і як зірочка співвідноситься з проєкціями out/ in. Наприкінці — практичні приклади й типові помилки.

Розбираємося, чому на JVM «стираються» узагальнені типи ( type erasure), через що заборонені перевірки на кшталт is T і List < Int >, і як легально робити перевірки та приведення через inline + reified. На практиці пишемо універсальні утиліти з as?, використовуємо T::class для повідомлень і збираємо елементи потрібного типу зі List < Any >.