Rado Buranský

Pattern matching is usually related to text search. In Scala it has much more sophisticated usage. You can write exciting decision logic when used together with case classes. Even after understanding what the two things mean I wasn’t able to use them as they deserve. It takes a while to really grasp them. Long and winding road.

Case classes allow easy pattern matching when otherwise complicated code would had to be written. See official documentation for introduction. Let’s look at some more interesting examples.

Exceptions are case classes

case class MyException(msg: String) extends Exception(msg)

The reason is that exception catching is in fact pattern matching. Catch block contains patterns and if there is a match then related piece of code is executed. Following code demonstrates this. The second case matches when the exception is either RuntimeException or IOException.

try { ...
} catch {
  case ex: MyException => Logger.error(ex.toString)
  case ex @ (_ : SQLException | _ : IOException) => println(ex)
}

Plain old data holders
If a class is designed to be just a data holder without any methods, it’s recommended to be a case class. It is syntactically easier to construct new instance and constructor parameters of a case class are by definition accessible from outside. Also they can be structurally decomposed using pattern matching. This is very handy.

Structural decomposition
Pattern is used not only to specify the conditions, but also to decompose the object being matched. Following example tries to find a tuple in a map based on provided key. If it finds one, it returns the second item of the tuple, which is a string. That’s the decomposition. In case it doesn’t find anything, it returns N/A. If you are curious why there are double brackets ((…)) then the reason is that the outer brackets are to denote function call and the inner brackets represent a tuple of two items.

def getValue(key: Int, data: Map[Int, (Int, String)]): String = {
  data.get(key) match {
    case Some((num, text)) => text
    case _ => "N/A"
  }
}

These two creatures occur more and more in my code. Yes, and not to forget, if you check the previous code you can see that the function should return a string, but there is no return statement. In Scala resulting value is the value of the last statement. Here we have more last statements depending on the pattern matching, but we cover all possible execution paths and we always return a string. Compiler is happy and we are too.

Scala encourages to use a functional style of programming. For programmers coming from imperative world of Java or C# it is the main challenge. The first step is to recognize the difference between functional and imperative programming. Scala has two keywords for variable declaration:

• var – mutable variables
• val – immutable variables

One sign of imperative sign is occurence of var in the code. Scala encourages to lean towards val, but use whatever is appropriate for the given situation.

Example of imperative style:

def printArgs(args: Array[String]): Unit = {
  var i = 0
  while (i < args.length) {
    println(args(i))
    i += 1
  }
}

More functional style:

def printArgs(args: Array[String]): Unit = {
  args.foreach(println)
}

Here you can see the reason why Scala encourages functional style. It helps you to write clearer, more understandable and less error-prone code. But you can do it even better. The refactored method is not purely functional. It has side effects – it prints to the standard output stream. One sign of a function with side effects is that its result type is Unit. If a function doesn’t return any value, it has either side effects or it is useless.

The most functional solution:

def formatArgs(args: Array[String]) = args.mkString("\n")
println(formatArgs(args))

Prefer vals, immutable objects and methods without side effects.