Advanced Patterns
⚙️ Advanced Patterns
📦 Value Classes — Type Safety with Zero Overhead
A common bug: a function taking two Int parameters (say, createUser(id: Int, age: Int)) is easy to call with the arguments accidentally swapped — the compiler can't catch it, since both are just Int. A value class wraps a single value in a distinct type that the compiler can tell apart, while compiling away to nothing extra at runtime:
At runtime, a UserId is represented as a plain Int wherever possible — the wrapper is erased by the compiler in most cases, so there's no extra object allocation or memory overhead compared to using a raw Int. The type safety is entirely a compile-time guarantee, at effectively zero runtime cost.
A value class must wrap exactly one val property, and can't have additional state — this single-property restriction is what makes the "erase to the underlying type" optimization possible. It can still have functions and computed properties, just no extra stored state beyond the one wrapped value.
➕ Operator Overloading
Marking a function operator lets it be called using an operator symbol instead of its name — Kotlin maps specific function names (plus, minus, times, compareTo, and others) onto +, -, *, comparison operators, and more:
Common Overloadable Operators
| Operator | Function Name | Operator | Function Name |
|---|---|---|---|
| a + b | plus | a[i] | get |
| a - b | minus | a[i] = v | set |
| a * b | times | a in b | contains |
| a > b / a < b | compareTo | a() | invoke |
| a == b | equals | -a | unaryMinus |
This is the same underlying idea as Java's lack of true operator overloading (Java only special-cases + for String concatenation) versus, say, Python's __add__ dunder methods — Kotlin's version is Python-like in spirit, but statically type-checked, and limited to a fixed, well-known set of operator names rather than allowing arbitrary custom syntax.
Operator overloading is genuinely useful for types where the operation has an obvious, unsurprising meaning (vectors, money, matrices). Overloading + on a type where it isn't intuitively "addition" (making user1 + user2 merge two accounts, say) tends to make code harder to read, not easier — the operator symbol should match what a reader would already guess it does.
📜 Contracts — Teaching the Compiler About Your Functions
Course 1's smart casts (Chapter 3) automatically narrow a nullable type after a built-in null check like if (x != null). A contract block extends that same smart-cast behavior to a custom function:
Without the contract block, name.length above wouldn't compile — the compiler has no way to know that isNotNullOrEmpty returning true guarantees name isn't null, since it's just an ordinary function as far as the compiler is concerned. The contract explicitly promises that relationship.
Contracts are not verified by the compiler — writing a contract that doesn't actually match the function's real behavior compiles fine, but produces incorrect smart-casts that can crash at runtime. This is genuinely advanced, low-level territory: most Kotlin code never writes a contract, and the standard library's own functions like isNullOrEmpty and requireNotNull are really the main examples worth knowing exist.
🏷️ Type Aliases — A Name, Not a New Type
typealias gives an existing type a new, more readable name — it's purely a compile-time label, not a distinct type the way a value class is:
UserMap and Map<String, List<Int>> are completely interchangeable to the compiler — a UserMap can be passed anywhere a Map<String, List<Int>> is expected and vice versa, with no conversion. That interchangeability is exactly the difference from a value class: typealias is for readability on complex generic types, not for type safety.
value class vs typealias
| value class | typealias | |
|---|---|---|
| Distinct type? | Yes — compiler tells it apart from the wrapped type | No — fully interchangeable with the original |
| Purpose | Type safety (prevent mixing up similar values) | Readability (shorten a long/complex type) |
| Runtime representation | Erased to the wrapped type where possible | N/A — never existed as a separate type |
💻 Coding Challenges
Challenge 1: A Value Class for Type Safety
Define two value classes, Meters(val value: Double) and Feet(val value: Double). Write a function fun metersToFeet(m: Meters): Feet that converts (1 meter = 3.28084 feet). Demonstrate calling it correctly, and add a commented-out line showing a call that would be a compile error (e.g. passing a Feet where Meters is expected).
Goal: Practice value classes preventing a realistic unit-mixup bug.
Challenge 2: Operator Overloading for a Money Type
Write a data class Money(val cents: Int) with overloaded plus (adding two Money values) and compareTo (comparing by cents) operators. Demonstrate adding two Money values with + and comparing two with >.
Goal: Practice writing operator functions with a genuinely intuitive use case.
Challenge 3: A Type Alias for a Callback
Define a type alias ValidationResult for Pair<Boolean, String> (valid flag + message), and a type alias Validator for (String) -> ValidationResult. Write a function fun validateUsername(): Validator returning a lambda that checks a username is at least 3 characters, returning an appropriate ValidationResult. Call it and print the result.
Goal: Practice using type aliases to make a function-type signature more readable.
Reach for a value class when two things share a primitive type but must never be mixed up. Reach for operator overloading when an operation on a custom type has an obvious real-world meaning. Reach for a type alias purely to make a complex type easier to read. Contracts are the outlier — worth understanding, rarely worth writing yourself.
🎯 What's Next
Next chapter — the final chapter of Kotlin Intermediate: Kotlin Multiplatform Basics — KMP intro, the expect/actual pattern, and sharing code across platforms.