The Compilation Mechanics of data class and sealed class

From "Boilerplate Hell" to "Compiler Delegation"

In the preceding article, we observed how the Kotlin compiler transposes concise class declarations into complete JVM bytecode—autonomously generating constructors, getters/setters, and backing fields. However, that is merely the prologue. When you require a class engineered purely as a "data carrier", Java mandates the manual implementation of equals(), hashCode(), toString(), and clone() methods. Every single one of these methods carries rigid contractual obligations, and manually writing them guarantees the eventual introduction of bugs.

Kotlin's data class eradicates this specific class of boilerplate code with a single keyword. Simultaneously, sealed class / sealed interface resolves another fundamental architectural crisis: Within a finite, closed type hierarchy, how do you compel the compiler to guarantee that "no possible condition has been omitted"?

This article conducts a deep dive into the compiled artifacts of these two mechanisms. You will comprehend exactly what code the compiler synthesizes on your behalf, the contracts this code honors, and the specific execution scenarios where you might step into traps.

The Magic of data class: What Exactly Did the Compiler Synthesize?

Code Generation Triggered by a Singular Keyword

When you prefix a class declaration with the data keyword:

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

The compiler seizes the properties declared exclusively within the primary constructor and autonomously synthesizes the following five members:

1. equals() —— Structural equality evaluation
2. hashCode() —— Hash code computation paired with equals()
3. toString() —— Formatted property stringification
4. copy() —— "Mutative copy" via named parameters
5. componentN() —— Destructuring declaration accessor functions

This is not superficial syntactic sugar. The compiler generates comprehensive, JVM-contract-compliant implementations for each method. Let us deconstruct them individually.

equals() and hashCode(): Primary Constructor-Driven Generation Rules

The equals() Synthesis Logic

The compiler-generated equals() strictly adheres to the universal contract of Object.equals() (Reflexivity, Symmetry, Transitivity, Consistency). Its execution logic unfolds as follows:

// Compiled equals() for: data class User(val name: String, val age: Int)
public boolean equals(Object other) {
    // ① Reference Equality—If they are the exact same physical object in memory, return true immediately
    if (this == other) return true;

    // ② Type Verification—If it is not the identical class type, return false immediately
    if (!(other instanceof User)) return false;

    User otherUser = (User) other;

    // ③ Sequential Property Comparison—Evaluating solely primary constructor parameters
    if (!Intrinsics.areEqual(this.name, otherUser.name)) return false;
    if (this.age != otherUser.age) return false;

    return true;
}

Critical architectural details to observe:

• Strictly compares primary constructor properties. Properties declared within the class body are aggressively excluded from equals() evaluation.
• Utilizes Intrinsics.areEqual() rather than a raw == operator. The former safely handles null values (equivalent to a?.equals(b) ?: (b === null)).
• Primitive types (e.g., Int) are evaluated utilizing raw != operators, evading catastrophic boxing overhead.

Visualize this as an identity card—two identity cards are deemed "equal" solely based on the ID number and primary fields printed on the card. It ignores where the card is physically located or what else the holder is carrying. Primary constructor parameters are the "fields printed on the card"; class body properties are the "other items the holder is carrying".

The hashCode() Synthesis Logic

The implementation of hashCode() rigorously deploys the classic "31 multiplier accumulator" algorithm—this is mathematically identical to the strategy employed by java.lang.String.hashCode():

// Compiled hashCode()
public int hashCode() {
    int result = this.name != null ? this.name.hashCode() : 0;
    result = 31 * result + Integer.hashCode(this.age);
    return result;
}

Why was 31 selected as the universal multiplier?

This was not a random roll of the dice; it is a meticulously calculated engineering decision:

The Array Property Trap

If your data class harbors an array property, the compiler-generated equals() and hashCode() will execute Reference Comparison, completely ignoring structural content:

data class Matrix(val values: IntArray)

val a = Matrix(intArrayOf(1, 2, 3))
val b = Matrix(intArrayOf(1, 2, 3))

println(a == b)       // false! —— Because IntArray.equals() executes strict reference comparison
println(a.hashCode() == b.hashCode())  // Highly probable to be false

This occurs because arrays natively inherit equals() from Object within the JVM, which evaluates solely via reference identity. If structural content comparison is mandatory, you are forced to manually override equals() and hashCode(), deploying contentEquals() and contentHashCode().

toString(): The Architecture of Formatted Output

The compiler-synthesized toString() emits all primary constructor properties in a strict ClassName(propertyName=value, ...) format:

// Compiled toString()
public String toString() {
    return "User(name=" + this.name + ", age=" + this.age + ")";
}

While superficially trivial, this delivers massive engineering value: Log Readability. Compared to Java's default User@1a2b3c output, User(name=Alice, age=30) allows immediate visual state extraction during debugging.

Equally critical, properties declared within the class body are violently suppressed from the toString() output:

data class User(val name: String, val age: Int) {
    var loginCount: Int = 0  // Expunged from toString() output
}

println(User("Alice", 30))  // Output: User(name=Alice, age=30)
// loginCount is completely "hidden"

copy(): The Shallow Copy Trap

Generation Mechanics

The copy() method empowers you to instantiate a replica of an object while selectively mutating specific properties. The compiler-synthesized implementation is fundamentally nothing more than a constructor invocation:

// Compiled copy() (Simplified)
public final User copy(String name, int age) {
    Intrinsics.checkNotNullParameter(name, "name");
    return new User(name, age);  // Direct execution of the constructor
}

// Synthetic method armed with default values—Deploying the identical bitmask architecture as constructors
public static User copy$default(User instance, String name, int age, int mask, Object marker) {
    if ((mask & 0x1) != 0) name = instance.name;   // If unprovided, inherit original value
    if ((mask & 0x2) != 0) age = instance.age;     // If unprovided, inherit original value
    return instance.copy(name, age);
}

Its deployment is highly intuitive:

val alice = User("Alice", 30)
val olderAlice = alice.copy(age = 31)
// Functionally identical to: new User("Alice", 31)

The Lethal Shallow Copy Trap

copy() executes a strict Shallow Copy. It replicates the "values" of the properties. However, for reference types, the "value" is the memory address pointer itself, NOT the physical object it points to.

Visualize copy() as photocopying a business card. The card states: "Safe Code: A123". After copying, you possess two physical cards, but both point to the exact same physical safe. If Person A utilizes the code to open the safe and removes the contents, Person B will subsequently find the safe empty.

Let us demonstrate this catastrophic failure mode in code:

data class Team(val name: String, val members: MutableList<String>)

val teamA = Team("Alpha", mutableListOf("Alice", "Bob"))
val teamB = teamA.copy(name = "Beta")

// teamB and teamA physically share the EXACT same MutableList instance in heap memory!
teamB.members.add("Charlie")

println(teamA.members)  // [Alice, Bob, Charlie] ← The original object suffered unintended mutation!
println(teamB.members)  // [Alice, Bob, Charlie]

Analyzed from a bytecode perspective, the failure is obvious—copy() executed new Team("Beta", this.members). It passed the raw memory reference of the original MutableList directly into the newly instantiated object.

Neutralizing the Shallow Copy Vulnerability

Optimal Practice: Mandate Immutable Collections

// ✅ RECOMMENDED: Deploy List to eradicate MutableList vulnerabilities
data class Team(val name: String, val members: List<String>)

val teamA = Team("Alpha", listOf("Alice", "Bob"))
val teamB = teamA.copy(name = "Beta")
// teamB.members.add("Charlie")  // ❌ COMPILE ERROR: List entirely lacks mutation methods like add()

If Mutability is Unavoidable: Implement Manual Deep Copying

data class Team(val name: String, val members: MutableList<String>) {
    // Manually architected Deep Copy methodology
    fun deepCopy(): Team = Team(name, members.toMutableList())
}

val teamA = Team("Alpha", mutableListOf("Alice", "Bob"))
val teamB = teamA.deepCopy()
teamB.members.add("Charlie")

println(teamA.members)  // [Alice, Bob] ← The original object remains secured
println(teamB.members)  // [Alice, Bob, Charlie]

The componentN() Functions: The Engine Behind Destructuring Declarations

Generation Rules

The compiler systematically synthesizes component1(), component2()... up to componentN() functions, mapping strictly to the declaration order of the primary constructor properties:

// Compiled output for: data class User(val name: String, val age: Int)
public final String component1() { return this.name; }
public final int component2() { return this.age; }

These functions act as the physical architectural foundation for Kotlin's Destructuring Declarations:

val user = User("Alice", 30)

// Destructuring Declaration
val (name, age) = user

// At compilation, this violently expands into:
val name = user.component1()  // "Alice"
val age = user.component2()   // 30

The Positional Trap: Destructuring Relies on Order, Not Nomenclature

Destructuring declarations are strictly position-based, entirely blind to nomenclature. This implies that if your variable names are mismatched with property names, the compiler will remain entirely silent, but runtime execution will extract catastrophic garbage data:

data class User(val name: String, val email: String)

val user = User("Alice", "alice@example.com")

// ⚠️ Variable names are inverted, yet the compiler issues ZERO warnings!
val (email, name) = user

println(email)  // "Alice"              ← This is physically the name!
println(name)   // "alice@example.com"  ← This is physically the email!

The compiler is blind to everything except sequence: email is structurally bound to component1() (the name property), and name is structurally bound to component2() (the email property).

Visualize post office boxes—the recipient purely reads the box number (Box 1, Box 2). They ignore any name tags stuck to the front. If you paste your own name tag onto Box 2, the envelope you extract will still be the contents intended for Box 2.

Deploying componentN() in for Loops and map Operations

Destructuring declarations extend far beyond localized variables; they deploy devastatingly powerful ergonomics during collection operations:

// Destructuring Map.Entry during Map traversal
val scores = mapOf("Alice" to 95, "Bob" to 87)
for ((name, score) in scores) {
    println("$name: $score")
}

// Destructuring within lambda payloads
val users = listOf(User("Alice", "alice@mail.com"), User("Bob", "bob@mail.com"))
users.forEach { (name, email) ->
    println("Email for $name is $email")
}

The underlying bytecode mechanics driving these syntax sugars are purely raw invocations of componentN() functions.

The Hard Limitations and Constraints of data class

The compiler forces a strict set of constraints upon data classes. Every single rule is anchored in a profound architectural rationale:

Why data class is Violently Prohibited from Inheritance

This is the absolute core to understanding data class architecture. Consider the catastrophic consequences if data class permitted the open modifier:

// ⚠️ HYPOTHETICAL: Assuming data class permitted 'open' (Physically forbidden)
open data class Person(val name: String)
data class Student(val name: String, val grade: Int) : Person(name)

val p: Person = Student("Alice", 5)
val q: Person = Person("Alice")

// What exactly does p.equals(q) evaluate to?

This triggers the legendary Symmetry Destruction Anomaly:

• Person.equals() evaluates solely name. It concludes that p == q.
• Student.equals() evaluates name AND grade. It concludes that p != q.
• This obliterates the mathematical symmetry contract of equals(): If a == b is true, then b == a MUST unequivocally be true.

The Kotlin architecture team surgically severed this vulnerability at the root: data classes are implicitly final and barred from inheritance. The compiler-generated equals() leverages instanceof for surgical type verification. Because behavioral correctness cannot be guaranteed across an inheritance hierarchy, inheritance is nuked entirely.

However, a data class is permitted to inherit from standard classes or implement interfaces:

// ✅ data class inheriting from an abstract class
abstract class Identifiable(val id: String)
data class Product(val name: String, val price: Double) : Identifiable("prod-001")

// ✅ data class implementing an interface
interface Printable { fun prettyPrint(): String }
data class Report(val title: String) : Printable {
    override fun prettyPrint() = "📄 $title"
}

The Underlying Mechanics of sealed class / sealed interface

Origin of the Crisis: The "Security Vulnerability" of Open Inheritance

In Java, when dispatching logic across a finite set of types, engineers routinely depend on extensive if-else blocks or switch chains. However, the Java compiler provides zero safety nets. If a new subtype is introduced and the engineer forgets to update the switch statement, the execution flow silently bleeds into the default branch, or worse, silently skips execution entirely.

Kotlin's sealed class annihilates this crisis at the compiler stratum: It informs the compiler of every single conceivable subtype within a type hierarchy, empowering the compiler to execute rigid Exhaustive Checks within when expressions.

Visualize a sealed class as a restaurant with a "fixed menu." The menu only possesses a strictly defined set of dishes. The ordering system (the compiler) guarantees that the kitchen has a standard operating procedure for every dish on the menu. If the kitchen adds a new dish (a new subclass), the system instantly triggers an alert: "You have not configured an output procedure for this new item."

Compile-Time Type Enumeration: How the Compiler Guarantees Known Subtypes

The foundational constraint of a sealed class: All direct subclasses MUST physically reside within the exact same compilation module as the sealed class. (Since Kotlin 1.1, subclasses can exist in different files within the same module; prior to 1.1, they were forced into nested declaration).

// Declared within Response.kt
sealed class Response {
    data class Success(val data: String) : Response()
    data class Error(val code: Int, val message: String) : Response()
    data object Loading : Response()
}

At the bytecode layer, a sealed class is physically compiled into an abstract class, and its constructor visibility is violently restricted to private (or protected):

// Compiled Response class
public abstract class Response {
    // Private constructor — Instantiation from external modules is physically blocked
    private Response() {}

    // Compiler-synthesized constructor exclusively for Kotlin subclasses
    // Mandates a DefaultConstructorMarker parameter, restricting invocation solely to the Kotlin Compiler
    public Response(DefaultConstructorMarker marker) {
        this();
    }
}

// Success operates as a subclass of Response
public static final class Success extends Response {
    private final String data;

    public Success(String data) {
        super((DefaultConstructorMarker) null);
        this.data = data;
    }
    // ... Complete data class implementations (equals/hashCode/toString/copy/componentN)
}

// Loading operates as a subclass of Response (data object = Singleton)
public static final class Loading extends Response {
    public static final Loading INSTANCE;
    
    private Loading() {
        super((DefaultConstructorMarker) null);
    }
    
    static {
        Loading var0 = new Loading();
        INSTANCE = var0;
    }
}

Critical observations:

1. The constructor of Response is strictly private—This mathematically prohibits external modules from injecting unauthorized subclasses at the bytecode level.
2. The compiler engineers a synthetic constructor (demanding DefaultConstructorMarker) to permit authorized module-internal subclasses to invoke the superclass constructor.
3. DefaultConstructorMarker is a highly restricted Kotlin compiler internal class. While a Java engineer could theoretically invoke it via aggressive hacks, it stands as an architectural "gentleman's agreement" that professional developers do not violate.

Kotlin Metadata and JVM 17+ PermittedSubclasses

The compiler persists the comprehensive subclass inventory in two critical locations:

At runtime, you can aggressively extract this subclass inventory via the kotlin-reflect library:

import kotlin.reflect.full.sealedSubclasses

// Extract every direct subclass of Response
val subclasses = Response::class.sealedSubclasses
// Result: [class Response.Success, class Response.Error, class Response.Loading]

Exhaustive Checks within when Expressions

The most devastating weapon in the sealed class arsenal is its integration with the when expression. The compiler weaponizes its internal subclass inventory to forcefully verify, at compile time, that every single branch has been accounted for:

fun handleResponse(response: Response): String = when (response) {
    is Response.Success -> "Payload: ${response.data}"
    is Response.Error   -> "Fault ${response.code}: ${response.message}"
    is Response.Loading -> "Initializing..."
    // Zero requirement for an 'else' branch — The compiler mathematically proves total coverage
}

If you attempt to comment out a branch, the compiler violently halts the build:

fun handleResponse(response: Response): String = when (response) {
    is Response.Success -> "Payload: ${response.data}"
    is Response.Error   -> "Fault ${response.code}: ${response.message}"
    // ❌ FATAL COMPILE ERROR: 'when' expression must be exhaustive,
    //    add necessary 'is Loading' branch or 'else' branch instead
}

The Bytecode Implementation of Exhaustive Checks

At the bytecode stratum, the when expression decomposes into a brutal chain of instanceof evaluations:

// Compiled when expression (Java Equivalent)
public static String handleResponse(Response response) {
    if (response instanceof Response.Success) {
        return "Payload: " + ((Response.Success) response).getData();
    } else if (response instanceof Response.Error) {
        Response.Error error = (Response.Error) response;
        return "Fault " + error.getCode() + ": " + error.getMessage();
    } else if (response instanceof Response.Loading) {
        return "Initializing...";
    } else {
        // Compiler-injected "Fallback Failure" for exhaustive when expressions
        throw new NoWhenBranchMatchedException();
    }
}

Observe the deployment of NoWhenBranchMatchedException at the tail end. Even though the compiler has mathematically proven branch coverage, it still injects this fallback exception into the bytecode. This is pure Defensive Programming: If a rogue subclass manages to infiltrate the execution environment at runtime (e.g., via a catastrophic binary compatibility collapse), the system detonates with a precise exception rather than silently swallowing the failure.

sealed class vs enum class: Strategic Decision Making

Both sealed class and enum class are engineered to model "finite type sets," but their architectural objectives are completely divergent:

High-Velocity Decision Matrix

Analyzing your type variants —
  │
  ├─ Are they merely disparate "Labels"? (e.g., MONDAY, TUESDAY)
  │   └─ Deploy enum class
  │
  ├─ Do they require carrying radically different data payloads? (e.g., Success holds data, Error holds exceptions)
  │   └─ Deploy sealed class
  │
  └─ Must they carry different payloads AND require specific variants to implement diverse interfaces?
      └─ Deploy sealed interface

Canonical deployment for enum class:

enum class HttpMethod { GET, POST, PUT, DELETE, PATCH }

enum class LogLevel(val priority: Int) {
    DEBUG(1), INFO(2), WARN(3), ERROR(4);

    fun shouldLog(minLevel: LogLevel): Boolean = this.priority >= minLevel.priority
}

Canonical deployment for sealed class:

sealed class NetworkResult<out T> {
    data class Success<T>(val data: T) : NetworkResult<T>()
    data class Error(val code: Int, val message: String) : NetworkResult<Nothing>()
    data object Loading : NetworkResult<Nothing>()
}

The absolute differentiator: The data payload structure ferried by Error (code + message) is structurally alien to the payload ferried by Success (data). An enum class is structurally incapable of modeling this asymmetry.

sealed interface: Obliterating the Single Inheritance Barrier

Kotlin 1.5 deployed sealed interface to obliterate a fundamental restriction of sealed class—the JVM Single Inheritance Limit.

// The Crisis: A class is architecturally limited to inheriting a singular sealed class
sealed class Error
sealed class Recoverable

// What if a specific fault type must be BOTH an Error and Recoverable?
// A sealed class cannot achieve this — Kotlin/JVM physically rejects multiple inheritance.

sealed interface unlocks multi-dimensional sealed taxonomy:

// Architecting two completely independent sealed dimensions
sealed interface Error
sealed interface Recoverable

// A specific type is now authorized to implement multiple sealed interfaces simultaneously
class NetworkError(val code: Int) : Error, Recoverable
class DatabaseError(val query: String) : Error
class AuthError(val reason: String) : Error, Recoverable

// Both dimensions are now authorized for isolated Exhaustive Checks
fun handleError(error: Error) = when (error) {
    is NetworkError -> retry(error.code)
    is DatabaseError -> logAndFail(error.query)
    is AuthError -> refreshToken(error.reason)
}

fun attemptRecovery(issue: Recoverable) = when (issue) {
    is NetworkError -> retryRequest()
    is AuthError -> reAuthenticate()
}

At the bytecode stratum, the compiled output of a sealed interface is practically indistinguishable from a standard interface. Sealing enforcement is driven entirely by the compiler's @Metadata annotations and module boundaries. The JVM itself is entirely oblivious to the interface's "sealed" nature (unless targeting Java 17+, which triggers PermittedSubclasses attribute generation).

Architectural Directive: Default to sealed interface to maximize structural flexibility. Fall back to sealed class strictly when shared state or constructor logic is an absolute necessity.

Tactical Operations: Architecting Type-Safe UI State via Sealed Classes

In Android architecture, the quintessential deployment of sealed classes is the modeling of UI State (UiState). Legacy architectures attempt to manage this via fragmented boolean flags and nullable fields (e.g., isLoading = true overlapping with data != null). This is a maintenance nightmare that routinely triggers "impossible state" anomalies.

The Result Paradigm

// Generic Sealed Class — Architected for all operation outcomes
sealed class Result<out T> {
    // Success: Payload ferried
    data class Success<T>(val data: T) : Result<T>()
    // Failure: Exception ferried
    data class Failure(val exception: Throwable) : Result<Nothing>()
}

// Tactical Extensions
fun <T> Result<T>.getOrNull(): T? = when (this) {
    is Result.Success -> data
    is Result.Failure -> null
}

fun <T> Result<T>.getOrThrow(): T = when (this) {
    is Result.Success -> data
    is Result.Failure -> throw exception
}

The UiState Paradigm

// UI State Architectural Modeling
sealed class UiState<out T> {
    // Cold State — Network activity uninitiated
    data object Idle : UiState<Nothing>()

    // In-Flight — Capable of ferrying legacy data to enable "Silent Refreshes"
    data class Loading<T>(val previousData: T? = null) : UiState<T>()

    // Resolution — Payload successfully acquired
    data class Success<T>(val data: T) : UiState<T>()

    // Fault — Exception intercepted, equipped with optional recovery execution block
    data class Error(
        val message: String,
        val retryAction: (() -> Unit)? = null
    ) : UiState<Nothing>()
}

Integration within Compose or legacy View ecosystems:

@Composable
fun <T> UiStateHandler(
    state: UiState<T>,
    onSuccess: @Composable (T) -> Unit
) {
    when (state) {
        is UiState.Idle -> { /* Render Zero Output */ }
        is UiState.Loading -> {
            CircularProgressIndicator()
            // Gracefully render legacy data if it exists during the refresh
            state.previousData?.let { onSuccess(it) }
        }
        is UiState.Success -> onSuccess(state.data)
        is UiState.Error -> {
            ErrorView(
                message = state.message,
                onRetry = state.retryAction
            )
        }
    }
    // The Compiler Mathematically Guarantees: Zero state conditions omitted
}

The engineering supremacy of this paradigm:

1. State Mutually Exclusive: It is mathematically impossible to simultaneously trigger Loading and Error states—the type system physically blocks it.
2. Data-State Coupling: data is exclusively bound to Success. Null-checks prior to usage are completely eradicated.
3. Bulletproof Extensibility: Injecting a new state variant (e.g., Empty) instantly triggers compilation failures across every when block in the codebase, forcing engineers to explicitly handle the new condition before merging.

Tiered Sealed Hierarchies

For high-complexity domain models, you can construct deep, multi-tiered sealed type trees:

sealed class PaymentState {
    data object Idle : PaymentState()

    sealed class Processing : PaymentState() {
        data class Authorizing(val transactionId: String) : Processing()
        data class WaitingFor3DS(val redirectUrl: String) : Processing()
    }

    sealed class Completed : PaymentState() {
        data class Success(val receipt: Receipt) : Completed()
        data class Refunded(val refundId: String, val amount: Double) : Completed()
    }

    data class Failed(val error: PaymentError) : PaymentState()
}

// Macro-resolution: Evaluating primary state tiers
fun getStatusLabel(state: PaymentState): String = when (state) {
    is PaymentState.Idle -> "Awaiting Input"
    is PaymentState.Processing -> "In-Flight"
    is PaymentState.Completed -> "Resolved"
    is PaymentState.Failed -> "Fault Intercepted"
}

// Micro-resolution: Surgically evaluating detailed sub-states
fun getDetailedLabel(state: PaymentState): String = when (state) {
    is PaymentState.Idle -> "Awaiting User Input"
    is PaymentState.Processing.Authorizing -> "Authorizing: ${state.transactionId}"
    is PaymentState.Processing.WaitingFor3DS -> "Awaiting 3DS Verification Pipeline"
    is PaymentState.Completed.Success -> "Transaction Authorized"
    is PaymentState.Completed.Refunded -> "Refund Issued: $${state.amount}"
    is PaymentState.Failed -> "Critical Fault: ${state.error}"
}

The Bytecode Panorama: The Complete Compiled Output of data and sealed classes

Let us construct a comprehensive code block that chains together every core architectural principle dissected in this article, and map them directly to their bytecode equivalents:

// ① sealed class: Architecting a finite type hierarchy
sealed class Shape {
    abstract fun area(): Double
}

// ② data class inheriting from the sealed class
data class Circle(val radius: Double) : Shape() {
    override fun area(): Double = Math.PI * radius * radius
}

data class Rectangle(val width: Double, val height: Double) : Shape() {
    override fun area(): Double = width * height
}

// ③ data object: A sealed subclass utterly devoid of instance data
data object Unknown : Shape() {
    override fun area(): Double = 0.0
}

// ④ Exhaustive when checks + Destructuring Declarations
fun describeShape(shape: Shape): String = when (shape) {
    is Circle -> {
        val (r) = shape              // Destructuring: Invokes component1()
        "Circle, Radius $r, Area ${shape.area()}"
    }
    is Rectangle -> {
        val (w, h) = shape           // Destructuring: Invokes component1() + component2()
        "Rectangle, $w × $h, Area ${shape.area()}"
    }
    is Unknown -> "Unidentified Geometry"
}

// ⑤ Deployment of copy()
fun growCircle(circle: Circle, factor: Double): Circle {
    return circle.copy(radius = circle.radius * factor)
}

The Compiled Output Manifest:

Design Philosophy Summary

Taking a macro view of the data class and sealed class architecture reveals three immutable design principles:

1. The Compiler is the Ultimate Code Generator

Every single one of the five automatically generated methods in a data class rigorously adheres to rigid JVM contracts. Failing to implement symmetry in equals(), or forgetting to align hashCode() with equals()—these are human errors. The compiler physically cannot commit these errors. By outsourcing boilerplate generation to the compiler, you reclaim cognitive bandwidth for actual domain logic.

2. The Type System is a Zero-Cost Safety Net

The exhaustive checks provided by sealed class are verified entirely at compile time. At runtime, they devolve into standard, high-speed instanceof checks—meaning they inflict zero runtime performance penalties. You secure absolute compile-time guarantees while paying zero operational tax. This is the essence of "Type-Driven Development": Weaponizing the type system to trap errors, rather than leaning weakly on test suites or code reviews.

3. Immutability is the Foundation of "Default Correctness"

The copy() operation in a data class executes a shallow copy. It is only mathematically safe if every single property it copies is structurally immutable. Deploying val instead of var, and List instead of MutableList—these are not philosophical dogmas; they are hard engineering mandates dictated directly by the compiler's internal behavior.

By mastering the true bytecode reality of data classes and sealed classes, you achieve surgical precision in your architectural decisions—when to deploy a data class vs a standard class; when to deploy a sealed class vs an enum; and identifying exactly when copy() is bulletproof vs when it is a trap. This is the foundational mental model required for engineering zero-defect code.