Using Scala Case Classes for Immutable Data Modeling

When to choose a Scala case class

Pick a case class when you need an immutable data holder that provides value‑based equality, a copy method for non‑destructive updates, and seamless pattern matching.

Worked example

Define a simple domain model for a user:

case class User(id: Long, name: String, email: String)

The compiler generates:

• equals and hashCode based on all fields (value equality).
• A copy method that lets you create a new instance with selected fields changed.
• Extractor support for pattern matching.

Create two instances with the same data and test equality:

val alice = User(1, "Alice", "[contact removed]")
val aliceCopy = User(1, "Alice", "[contact removed]")
println(alice == aliceCopy) // true – value equality

Use copy to update the email without mutating the original:

val aliceUpdated = alice.copy(email = "[contact removed]")
println(alice.email)          // [contact removed] (unchanged)
println(aliceUpdated.email)   // [contact removed]

Pattern match on the sealed hierarchy (optional but common):

sealed trait UserStatus
case object Active extends UserStatus
case object Inactive extends UserStatus

case class RichUser(id: Long, name: String, status: UserStatus)

def greet(user: RichUser): String = user match {
  case RichUser(_, name, Active)   => s"Hello, $name!"
  case RichUser(_, name, Inactive) => s"Welcome back, $name."
}

println(greet(RichUser(2, "Bob", Active))) // Hello, Bob!

Limits and common mistakes

Performance overhead with many fields

Each copy creates a new object; if a case class has dozens of fields and is copied frequently, allocation pressure can rise. Consider using @inline methods or a custom builder for hot paths.

Accidental mutability

Declaring a var inside a case class breaks value‑based equality because two instances with the same val fields but different var values compare equal incorrectly. Keep all fields val (or make the case class final and avoid var).

Deeply nested updates

Updating a field deep inside a nested case class leads to verbose code: outer.copy(inner = inner.copy(field = newValue)). Introduce lenses (e.g., from the monocle library) or use a wrapper method to reduce boilerplate.

Practical verification

1. Define a case class and instantiate two objects with identical field values.
2. Assert obj1 == obj2 returns true (value equality).
3. Call copy on one instance, modify a field, and confirm the original instance’s fields remain unchanged.
4. If using a sealed trait, compile with -Xlint:unused or -Xlint:nonvariance to see warnings for non‑exhaustive pattern matches.