Kotlin Data Classes: Automatic Boilerplate for Data Holders
A Kotlin data class automatically generates boilerplate like equals() and toString() for classes that just hold data. Use it for model objects or DTOs where value equality matters. The footgun: its copy() method is shallow, sharing mutable objects.
Why it exists
In Java, creating a simple data-holding class (a POJO) requires manually writing lots of boilerplate: constructors, getters, equals(), hashCode(), and toString(). This is repetitive and error-prone. Kotlin's data class solves this by having the compiler generate this code automatically from a single-line declaration.
The mental model
Think of a data class as a contract with the compiler. You declare the data your class holds in its primary constructor, and in return, the compiler provides a standard set of functions for comparing, printing, and copying that data. It's a class focused on what it is (its data), not what it does (its behavior).
How it works
By adding the data keyword before class, you instruct the Kotlin compiler to generate several members based only on the properties in the primary constructor. These are: equals() and hashCode() for value-based comparison; toString() for a readable representation like "User(name=John, age=42)"; componentN() functions that enable destructuring declarations like val (name, age) = user; and a copy() function to create a new instance with potentially modified properties. Properties declared inside the class body are not included in these generated functions.
When to use it
Use data classes for any plain data holders. This is common for: first, representing models from a database or API (Data Transfer Objects or DTOs); second, managing immutable state in your application, especially in functional-style programming; and third, returning multiple values from a function, where a named data class is more readable than a generic Pair.
When not to use it
Avoid data classes when a class's identity is more important than its data, or when it has complex behavior. A network manager or database connection handler should not be a data class, as two instances are never truly "equal". Also, data classes cannot be abstract, open, sealed, or inner, which limits their use in certain inheritance hierarchies.
One canonical example
The copy() function is powerful but creates a shallow copy. If a data class holds a mutable object, like a list, both the original and the copy will point to the same list instance. For example, consider data class Team(val name: String, val members: MutableList<String>). If you create originalTeam and then copiedTeam = originalTeam.copy(), adding a member to copiedTeam.members will also add it to originalTeam.members. This happens because copy() duplicated the reference to the list, not the list itself.
Interview question
Which statement accurately describes the behavior of the copy() method generated for a Kotlin data class?
- a.It creates a new instance where all properties, including nested mutable objects, are deep copied.
- b.It is primarily used for destructuring declarations, not for creating new instances.
- c.It only copies properties that are explicitly marked as val in the primary constructor.
- d.It performs a shallow copy, meaning references to mutable objects within the data class are shared between the original and the new instance.Correct
Why? this is the answer
The card explicitly states that the copy() function creates a shallow copy. This means if a data class contains a mutable object, both the original and the copied instance will refer to the same mutable object. Option A is a common misconception, as many expect a copy function to perform a deep copy for safety.
Just read this? Test yourself on what you have been reading.
Read the original → kotlinlang.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kotlin — each one lists the topics its interview covers.
See open roles