log4p

Peter Maas’s Weblog

ScotchBuilder with Scala 2.8

December 23rd, 2009 | Category: dsl, scala

While writing my internal SQL DSL example I stumbled upon this blogpost about a Type-safe Builder Pattern in Scala a couple of times. One of the issues I have with that code is the unnecessary use of mutable state in the example. Which are probably there to demonstrate the validation of the result at the end of the article.

The blogpost concludes with some complex implicit solution to have the builder only create valid configurations, but (IMHO) fails to address the fact that it is still possible to create OrderOfScotch variants which are invalid through its' constructor.

With Scala 2.8 it is possible to vastly simplify the example by using the the copy method on the case classes and default arguments:

PLAIN TEXT
  1. sealed abstract class Preparation
  2. case object Neat extends Preparation
  3. case object OnTheRocks extends Preparation
  4. case object WithExtraWater extends Preparation
  5.  
  6. sealed abstract class Glass
  7. case object Short extends Glass
  8. case object Tall extends Glass
  9. case object Tulip extends Glass
  10.  
  11. case class OrderOfScotch(val brand:String , val mode:Preparation = Neat, val double:Boolean = false, val glass:Option[Glass] = None) {
  12.   val invalid: Boolean = double && glass.isDefined && glass.get == Short
  13.   if(invalid) {
  14.       throw new IllegalStateException("Illegal combination")
  15.   }
  16.  
  17.   def prepare(p:Preparation) = copy(mode = p)
  18.   def isDouble(d:Boolean) = copy(double = d)
  19.   def inGlass(g:Glass) = copy(glass = Option(g))
  20. }
  21.  
  22. object OrderBuilder {
  23.   def scotch(brand:String) = OrderOfScotch(brand)
  24. }

Using the above you can write something like:

PLAIN TEXT
  1. val scotchOrder1 = scotch("Glenfoobar") prepare WithExtraWater inGlass Tulip
  2. val scotchOrder2 = scotch("Talisker") inGlass Tall prepare Neat

When using an incorrect configuration (in the example implementation a double scotch, in a short glass) creating the Order throws an exception. And since we in effect only use the constructor to create the Order this works in any case.

Consider the following tests:

PLAIN TEXT
  1. class ScotchBuilderSpec extends Spec with ShouldMatchers {
  2.   import OrderBuilder._
  3.   describe("given two scotches with the same configuration") {
  4.     val constructorResult = OrderOfScotch("Glenfoobar", WithExtraWater, false, Option(Tulip))
  5.     val builderResult = scotch("Glenfoobar") prepare WithExtraWater inGlass Tulip
  6.  
  7.     describe("when created by constructor and by the builder") {
  8.       it("they should return identical results") {
  9.         constructorResult should be (builderResult)
  10.         println("success!")
  11.       }
  12.     }
  13.   }
  14.  
  15.   describe("trying to create an illegal order") {
  16.     describe("like combining a double portion with a short glass") {
  17.       it("should throw an exception, for now") {
  18.         evaluating { OrderOfScotch("Glenfoobar", Neat, true, Option(Short)) } should produce[Throwable]
  19.         evaluating { scotch("Glenfoobar") isDouble(true) inGlass Short } should produce[Throwable]       
  20.       }
  21.     }
  22.   }
  23. }

As you can see the amount of boilerplate code was reduced dramatically, we've got rid of all mutable state and moved validation of the Order to a (IMHO) better location!

One 'drawback' of my solution is of course that it only works on runtime; whereas the solution presented in the catches incorrect configurations created by the builder at compiletime... which was the entire point of that blogpost. I'll try and see if I can factor that into a more compact form as well lator on!

2 comments

2 Comments so far

  1. Erik van Oosten December 23rd, 2009 10:32 am

    Another drawback of this solution is that problems without a good set of default values can not be expressed this way due to the validation check in the constructor.

    BTW, I think the IllegalStateException should be an IllegalArgumentException :)

  2. peter December 24th, 2009 7:33 pm

    You are right. Both cases. I will need to revise my refactor; I simplified the validation part way to much.

Leave a reply