Case Classes delves deeper into the
switch power in Scala, and also describes some seemingly disparate ways of saving you a lot of lines of code. Extractor Objects explains how the values are extracted.
Suppose you are creating a logging system like log4j that can log a
Exception, or both. Suppose further that you wish to keep stack traces to a minimum and only output them for
Error exceptions that are logged, or for any exception logged at the
There are several possible means of implementing this in Java. Here is one such implementation:
There’s a lot of repetition here, and the conciseness of the
log method can make it a bit hard to grok at first.
Scala’s case classes provide a lot of features to help. Here’s a possible implementation in Scala:
The simple addition of the
case keyword before the three extenders of the log message class does a whole lot:
- properties to access the constructor arguments are created automatically
equalsmethod based on the constructor arguments is created
toStringimplementation is provided that uses the constructor arguments
- instances can be created without the
newoperator, just the classname is needed
- the constructor arguments can be extracted in one statement, as we do in the
match block itself also packs quite a bit of functionality. Think of it as a
switch statement on steroids. In this case, we are “switching” on, among other things, the type of
l, the log message. Each
case expression allows us to implement a function that uses the extracted constructor arguments. The match is determined more or less as follows:
In the code here, the first case statement executes if
l is of type StringMessage, and, if so, “pulls out” the message that was passed to its constructor.
We can also match a case statement with conditions beyond just the type of
l. The second
case statement is executed if
l is an ExceptionMessage and if the extracted argument from
l is of type
l is an ExceptionMessage, but was not created with an exception that is a subclass of
Error, we don’t match and proceed to the next
case to check for a match.
The next statement will match if
l is of type ExceptionMessage and if
l ’s exception argument was any type of
Throwable,however there is a guard condition; if the log level passed to
log is less than 5, we match and execute this code. If not, we proceed looking for another match.
The subsequent statement will match any other ExceptionMessage that wasn’t matched by the first two (because we have no type on the argument, and no guard conditions).
This may sound complicated in explanation, but look back at the code. It’s actually pretty clear what’s going on now that you’ve got some hints as to the meaning of the syntax.
We’ve simplified some complex logic by reducing line count and repetition, and we’ve also avoided having to have nine different methods to cover all of our cases.
Now look back at the Java code. We certainly could have implemented our Java logger using a similar log message class hierarchy to reduce those nine methods to three, but the required classes would require several lines of code each (compared to Scala’s one) and would not have the ability to extract their arguments so concisely.
Like ScalaFunctions , case classes are far more powerful than what is shown here, but this shows you another means of simplifying your codebase.
You’ll notice in the various
case clauses that the values are extracted out of the class. This is done via a method called
unapply, and a huge amount of syntactic sugar. In the standard way of using this (and, as used here with case classes),
unapply takes arguments of the types given to the constructor and returns an
Option is a class used to return either a valid value or no value; a more formal way of possibly returning null; you can test if a value was returned and get it. This is how Scala determines if a match is made. If
unapply returned a value (based on the
Option instance returned), there is a match and the code executes. If a value isn’t returned (i.e. the
Option is a wrapper for
None), there is no match and the next case is checked.
For example, the
unapply for BothMessage would return a
Option[(String,Throwable)], which is to say a tuple of size 2 with a
String in the “0” position and a
Throwable in the “1” position.
My Thoughts on this Feature
It’s certainly not remotely intuitive that putting
case before a class definition would give you the automatic stuff it gives you. I want this stuff outside of ever needing to use a class in a case statement, and so it just seems weird to call it “case classes”.
That being said, it’s pretty darn useful and anything that saves me from typing the same code over and over is a win. The “deconstruction” bit is also pretty cool, even if the underpinnings of how it works are hard to follow.
unapply is highly subtle and a really huge bit of hand-waving, but is obviously the way in which the case class stuff has to be implemented. It’s hard to come up with a use for it outside of this, and I’m not clear on when you’d write your own instead of just relying on the