What is a computed property in Kotlin, and how do you write one using a custom get()?
answer
- Custom get() = derived value
- No 'field' reference => no backing field
- Use val, recomputed every read
- Property for cheap/pure, function for expensive/params
basics
~10 sA computed property has no stored value. Each time you read it, a custom get() runs and calculates the result on the fly from other data, instead of returning something saved in memory.
solid answer
~40 sA computed property is a property whose value is derived on every read by a custom getter rather than stored. You declare it with `val name: T get() = expression`. Because the getter computes the value, Kotlin allocates no backing field (`field`) for it. It behaves like a zero-argument method but reads like a property, which keeps call sites clean (`person.fullName` not `person.fullName()`). Use `val` since there is nothing to store and assign. Common uses: `isEmpty get() = size == 0`, formatting, and aggregating other properties. Compared to a function, a computed property signals 'cheap, side-effect-free derived state'; expensive or parameterized work should stay a function.
code
kotlin · 4 linesclass Order(val items: List<Item>) {
val total: Double
get() = items.sumOf { it.price } // computed each read, nothing stored
}go deeper
Can write val area get() = width * height and explain it computes on read with no stored value.
Articulates 'no backing field because field is never referenced' and recomputation on every access.
Discusses property-vs-function style guidance (cheap/pure vs expensive/params) and lazy caching for hot paths.
Frames computed properties as API design: predictable, side-effect-free reads, and the cost contract callers implicitly assume.
## What 'property' means in Kotlin A Kotlin property is a named member you read/write with field-like syntax (`obj.x`). Under the hood the compiler generates a getter (and a setter for `var`). For a normal property like `var x = 0`, the compiler also creates a hidden **backing field** — actual memory that stores the value. ## Computed property = custom get(), no backing field A **computed property** replaces the default getter with your own `get()` that returns a calculated value. Because the getter never refers to the special `field` identifier, the compiler generates **no backing field** — nothing is stored. The value is recomputed on every read. ```kotlin class Rectangle(val width: Int, val height: Int) { val area: Int get() = width * height // recomputed each read, no storage val isSquare: Boolean get() = width == height } ``` Key points: - Use **`val`**, not `var`: there is nothing to assign, so a setter makes no sense. - The getter can be written as an expression body `get() = ...` or a block `get() { ... return ... }`. - It runs **every** time the property is read, so each access re-evaluates the expression. ## Property vs function A computed property is semantically close to a parameterless function. Kotlin style guidance: prefer a **property** when it's cheap, has no side effects, and just describes derived state (e.g. `size`, `isEmpty`, `fullName`). Prefer a **function** when it's expensive, throws, or takes arguments. ```kotlin class Person(val first: String, val last: String) { val fullName: String get() = "$first $last" // property: cheap, pure fun greeting(lang: String) = "..." // function: takes a param } ``` ## Type inference caveat With a custom getter you usually still declare the type explicitly (`val area: Int`). Kotlin can infer it from the getter, but being explicit is the common, readable style.
- Why use val and not var for a computed property?Because there is no stored value to assign; the value is derived from other state. A var would imply a setter, but you cannot meaningfully store into something that has no backing field.
- Does the getter run once or on every access?On every access. If the computation is expensive, cache it (e.g. with `by lazy`) instead of recomputing each read.
Like a spreadsheet formula cell: it stores no number, it recalculates from other cells whenever you look at it.
saying these in an interview costs you the question
- Claiming a computed property stores its result like a normal field
- Saying the getter runs only once and is cached automatically
- Using var for a derived property that has no backing field
- Confusing it with a Java field plus getter method