Java developers often rely on switch/case statements when evaluating one of a set of possible values. Such evaluation is done, for instance, when parsing a tree structure. Switch and case have many limitations in Java—case can only take an int, for example—and many developers have come to believe that frequent uses of switch/case makes large code bases fragile.

Scala provides pattern matching as a more elegant and extensible way to accomplish what switch/case can do in Java. Case classes are used in pattern matching, and allow the compiler to help implement proper pattern matching. In chapter 15 of Programming in Scala, Martin Odersky, Lex Spoon, and Bill Venners describe case classes as:

Case classes are Scala’s way to allow pattern matching on objects without requiring a large amount of boilerplate. In the common case, all you need to do is add a single case keyword to each class that you want to be pattern matchable...:

case class Var(name: String) extends Expr 

Classes with such a modifier are called case classes. Using the modifier makes the Scala compiler add some syntactic conveniences to your class.

For instance, the compiler adds a factory method with the name of the class, makes all parameter values to the class vals (they can't be re-assigned), and adds sensible toString(), hashCode(), and equals() method implementations to the class. These changes together facilitate case classes to be used in pattern matching.

In a recent blog post, Are Scala's Case Classes a Failed Experiment?, Cedric Beust wonders if case classes, as implemented in Scala, actually achieve their goal of simplifying pattern matching:

Ever since I first read about case classes, I have been confused about their utility, and my puzzlement has not abated. Either I am missing something big or this feature is something that has been vastly overhyped and that should be avoided as much as possible...

When I exposed the crux of this argument to a few Scala experts, they overall agreed about the point and responded by pointing out that case classes were more useful as an alternative to the Visitor pattern.

Before turning our attention to this specific case, it's important to note that at this point, we are now looking at solving a niche problem. And quite a rare one, in my experience. If this is really the reason why case classes were invented, I am really left scratching my head about the decision to include such a big feature inside a language to solve such a small class of problems.

Visitors are used to emulate multiple dispatch in languages that don't support it natively. In some way, you are extending virtual invocation to apply to the runtime type of parameters passed to your functions...

Beust's argument centers around examples in the online Scala documentation that can actually make an object model more interdependent and, hence, harder to maintain.

What do you think about Scala's case classes?

def recursiveFunction(aList: List[T]): List[T] = aList match {
 case List() => ...
 case head :: tail => head doSomethingWith recursiveFunction(tail)
 case else => ...
}

} catch (FileNotFoundException e) {
   // ...
} catch (IOException e) {
   // ...
} catch (RuntimeException e) {
   // ...
} catch (Exception e) {
   // ...
}