Data Exposure and Encapsulation

TL;DR – Scala lets you expose internal data, then later change underpinnings while maintaining the same interface.

The functional Way is an open Way. Internal data is available to anyone who wishes to extract it.

“But what about encapsulation??” – horrified OO programmer
“We do not fear your code, for you cannot screw up our immutable data.” – calm FP programmer
“But what about change? If you expose internal structure, then you can never change internal structure. You’ll break all my code!” – OO
“The surface is resilient. The essence is fluid. We can keep client code happy while expanding underneath.” – FP

One of the ways that Scala achieves “scalability” is: make the code easy to write now, and still flexible to change later. An example is simple data structures: the case class. By default, anyone can pattern match to extract all the values from a case class. For instance:

case class PersonName(first: String, last: String)
val me = PersonName(“Jessica”, “Kerr”)

val greeting = me match {
  case PersonName(first, last) => s”Hello, $first $last”
}

This is handy – it makes building and using simple datatypes painless. Fields are public, which is not frightening because they’re final, safe from alteration.

The danger of this easy syntax is rigidity: if I add a middle-name field to PersonName, then all the code that pattern matched on it is broken. Construction, too.

case class PersonName(first: String, 
                      last: String, 
                      middle: Option[String])
val me = PersonName(“Jessica”, “Kerr”) // broken!

me match {
  case PersonName(first, last) => s”Hello, $first $last” // broken!
}

We want to change the PersonName without breaking backwards compatibility. In Scala, all the handiness of the case class (construction, extractors) is syntax sugar. That means we can pull it apart and do whatever we want with it behind the scenes.

In Scala, the constructor that works without “new” in front of it is really function application on the PersonName companion object. [1] And function application on anything is really a call to its apply method. Case class syntax sugar provides an apply method that accepts all the fields, like:

object PersonName {
     def apply(first: String, 
               last:String, 
               middle: Option[String]) : PersonName =
            new PersonName(first, last, middle)
   …
}

PersonName(“first”, “last”, Some(“middle”)) expands to PersonName.apply(“first”, “last”, Some(“middle”)) .
Since that’s all the case class constructor really is, we can re-enable the old syntax by adding a bonus apply method to the PersonName object:

object PersonName {
    def apply(first: String, last: String): PersonName = 
       new PersonName(first,last, None)
}
val me = PersonName(“Jessica”, “Kerr”) // fixed!

There’s another secret method name behind the pattern match syntax. When Scala sees:

(p : PersonName) match {
   case PersonName(a : String,b : String) =>
}

Scala looks for a method called unapply on the PersonName object; unapply should accept a PersonName and return an optional tuple of two strings.

object PersonName {
  def unapply(pn: PersonName): Option[(String, String)] = 
       Some((pn.first, pn.last))
}

It’s like the case statement is switching around the return value and the arguments of the unapply method. If calling unapply with the matched-against value (p) returns Some(tuple), then the match succeeds and the identifiers (a and b) get the values in the tuple.

Retaining support for the pattern match is harder than the constructor. We can’t add another unapply extractor to the PersonName object; it conflicts with the generated one that comes with the case class.

Here’s a solution that abstracts PersonName into a trait, then backs it with a different case class of our choice. Now the constructors and extractors are ours to control and manipulate.

trait PersonName {
    val first:String
    val last:String
  }

case class FullPersonName(first: String, 
              last: String,
              middle: Option[String]) extends PersonName

object PersonName {
  def apply(first: String, last: String): PersonName = 
          FullPersonName(first,last, None)
  def unapply(pn: PersonName): Option[(String, String)] = 
          Some((pn.first, pn.last))
}

This compatibility could also be met by changing PersonName from a case class into a regular class, and supplying apply and unapply methods as we like. What matters is not how we do it, but that we can.

In this way Scala makes the obvious thing easy, and custom behavior possible. Backwards compatibility enables reuse. In OO we encapsulate everything up front to make later change possible, with indirection and lots of boilerplate. In Scala we don’t have to complicate our code to accommodate possible imagined future change. Stick with YAGNI now, without paying for it later. Reduced suffering for everyone! The world is a better place with FP.

————–
[1] We could fix the broken constructor by supplying a default value for middle name.

case class PersonName(first: String, 
                      last: String,
                      middle: Option[String] = None)

That’s simpler but less flexible.