Что такое data class в Kotlin

А, ну вот, смотри, это же одна из тех штук, за которые Котлин реально любят. Data class, блядь. Ну представь себе, обычный класс, но такой ленивый, что ему впадлу каждый раз руками equals, hashCode и toString писать. Вот ты объявляешь его с волшебным словом data — и он тебе, ядрёна вошь, сам всё это генерирует. Красота же!

Вот смотри, самый простой пример, чтоб не ебать копать:

data class User(val name: String, val age: Int)

Всё. И из этого, казалось бы, хуй с горы, ты получаешь кучу плюшек нахаляву. Создал объект — val vasya = User("Вася", 30). Захотел посмотреть, что внутри — println(vasya). И тебе не какая-то херня типа User@4f023edb выведется, а нормальная, человеческая строка: User(name=Вася, age=30). Удобно, ёпта.

А если нужно сравнить два объекта, не надо городить огород с проверкой каждого поля. Просто vasya == petya, и всё работает как надо, потому что equals и hashCode уже под капотом. Волнение ебать, как просто.

Но самое, блядь, вкусное — это copy(). Допустим, твой Вася постарел на год. Вместо того чтобы создавать нового Васю и копировать все поля, ты делаешь так:

val olderVasya = vasya.copy(age = 31)

Старый объект не трогается, создаётся новый, и только возраст меняется. Остальные поля — как были. Пизда рулю, правда же?

Ну и деструктуризация, это когда объект можно разобрать на части, как конструктор наоборот:

val (userName, userAge) = vasya
// теперь userName = "Вася", userAge = 30

Но, чувак, есть же и подводные камни, куда без них. Data class — он как красивый, но строгий костюм. Надевать его нужно только по делу.

Во-первых, все параметры в первичном конструкторе обязательно должны быть val или var. Иначе компилятор тебе такое выскажет... Чёрта в душу, в сердцу мать!, не скомпилируется просто.

Во-вторых, он для данных, а не для логики. Если тебе нужно запихнуть туда кучу методов, бизнес-правил и прочей ебанины — это не сюда. Бери обычный class и не мучай data class. Он от этого грустит.

И ограничения, блядь, тоже имеются:

• Наследоваться от него нельзя. Ты не можешь сделать class SuperUser : User(...). Сам — final, и точка. Хочешь иерархию — делай обычный открытый класс.
• Он не может быть abstract, open, sealed или inner. Он сам по себе, этакий самодостаточный полупидор в хорошем смысле слова.

Короче, инструмент офигенный, но нужно понимать, где его применять. Для передачи данных между слоями, для моделей ответа от API, для простых value-объектов — идеально. Для всего остального — уже нет. Э бошка думай, когда выбираешь.