score:132

Accepted answer

My preferred way of avoiding case class inheritance without code duplication is somewhat obvious: create a common (abstract) base class:

abstract class Person {
  def name: String
  def age: Int
  // address and other properties
  // methods (ideally only accessors since it is a case class)
}

case class Employer(val name: String, val age: Int, val taxno: Int)
    extends Person

case class Employee(val name: String, val age: Int, val salary: Int)
    extends Person


If you want to be more fine-grained, group the properties into individual traits:

trait Identifiable { def name: String }
trait Locatable { def address: String }
// trait Ages { def age: Int }

case class Employer(val name: String, val address: String, val taxno: Int)
    extends Identifiable
    with    Locatable

case class Employee(val name: String, val address: String, val salary: Int)
    extends Identifiable
    with    Locatable

score:8

In these situations I tend to use composition instead of inheritance i.e.

sealed trait IVehicle // tagging trait

case class Vehicle(color: String) extends IVehicle

case class Car(vehicle: Vehicle, doors: Int) extends IVehicle

val vehicle: IVehicle = ...

vehicle match {
  case Car(Vehicle(color), doors) => println(s"$color car with $doors doors")
  case Vehicle(color) => println(s"$color vehicle")
}

Obviously you can use a more sophisticated hierarchy and matches but hopefully this gives you an idea. The key is to take advantage of the nested extractors that case classes provide

score:14

case classes are perfect for value objects, i.e. objects that don't change any properties and can be compared with equals.

But implementing equals in the presence of inheritance is rather complicated. Consider a two classes: 

class Point(x : Int, y : Int)

and 

class ColoredPoint( x : Int, y : Int, c : Color) extends Point

So according to the definition the ColorPoint(1,4,red) should be equal to the Point(1,4) they are the same Point after all. So ColorPoint(1,4,blue) should also be equal to Point(1,4), right? But of course ColorPoint(1,4,red) should not equal ColorPoint(1,4,blue), because they have different colors. There you go, one basic property of the equality relation is broken.

update

You can use inheritance from traits solving lots of problems as described in another answer. An even more flexible alternative is often to use type classes. See What are type classes in Scala useful for? or http://www.youtube.com/watch?v=sVMES4RZF-8

score:45

Since this is an interesting topic to many, let me shed some light here.

You could go with the following approach:

// You can mark it as 'sealed'. Explained later.
sealed trait Person {
  def name: String
}

case class Employee(
  override val name: String,
  salary: Int
) extends Person

case class Tourist(
  override val name: String,
  bored: Boolean
) extends Person

Yes, you have to duplicate the fields. If you don't, it simply would not be possible to implement correct equality among other problems.

However, you don't need to duplicate methods/functions.

If the duplication of a few properties is that much of an importance to you, then use regular classes, but remember that they don't fit FP well.

Alternatively, you could use composition instead of inheritance:

case class Employee(
  person: Person,
  salary: Int
)

// In code:
val employee = ...
println(employee.person.name)

Composition is a valid and a sound strategy that you should consider as well.

And in case you wonder what a sealed trait means — it is something that can be extended only in the same file. That is, the two case classes above have to be in the same file. This allows for exhaustive compiler checks:

val x = Employee(name = "Jack", salary = 50000)

x match {
  case Employee(name) => println(s"I'm $name!")
}

Gives an error:

warning: match is not exhaustive!
missing combination            Tourist

Which is really useful. Now you won't forget to deal with the other types of Persons (people). This is essentially what the Option class in Scala does.

If that does not matter to you, then you could make it non-sealed and throw the case classes into their own files. And perhaps go with composition.


Related Query

More Query from same tag