Let’s revisit the HTTP method script, which uses a sealed case class hierarchy versus the version we wrote previously that uses an Enumeration. Since the enumeration version doesn’t handle the message body, let’s write a modified version of the sealed case class version that is closer to the enumeration version, i.e., it also doesn’t hold the message body and it has name and id methods:

// code-examples/AppDesign/enumerations/http-case-script.scala

sealed abstract class HttpMethod(val id: Int) {
  def name = getClass getSimpleName
  override def toString = name
}

case object Connect extends HttpMethod(0)
case object Delete  extends HttpMethod(1)
case object Get     extends HttpMethod(2)
case object Head    extends HttpMethod(3)
case object Options extends HttpMethod(4)
case object Post    extends HttpMethod(5)
case object Put     extends HttpMethod(6)
case object Trace   extends HttpMethod(7)

def handle (method: HttpMethod) = method match {
  case Connect => println(method + ": " + method.id)
  case Delete  => println(method + ": " + method.id)
  case Get     => println(method + ": " + method.id)
  case Head    => println(method + ": " + method.id)
  case Options => println(method + ": " + method.id)
  case Post    => println(method + ": " + method.id)
  case Put     => println(method + ": " + method.id)
  case Trace   => println(method + ": " + method.id)
}

List(Connect, Delete, Get, Head, Options, Post, Put, Trace) foreach {
  method => handle(method)
}

Note that we used case object for all the concrete subclasses, to have a true set of constants. To mimic the enumeration id, we added a field explicitly, but now it’s up to us to pass in valid, unique values! The handle methods in the two implementations are nearly identical.

This script outputs the following:

Main$$anon$1$Connect$: 0
Main$$anon$1$Delete$: 1
Main$$anon$1$Get$: 2
Main$$anon$1$Head$: 3
Main$$anon$1$Options$: 4
Main$$anon$1$Post$: 5
Main$$anon$1$Put$: 6
Main$$anon$1$Trace$: 7

The object names are ugly, but we could parse the string and remove the substring we really care about.

Both approaches support the concept of a finite and fixed set of values, as long as the case class hierarchy is sealed. An additional advantage of a sealed case class hierarchy is the fact that the compiler will warn you if pattern matching statements aren’t exhaustive. Try removing one of the case clauses and you’ll get the usual warning. The compiler can’t do this with enumerations, as we saw.

The enumeration format is more succinct, despite the name duplication we had to use, and it also supports the ability to iterate through the values. We had to do that manually in the case clause implementation.

The case class implementation naturally accommodates other fields, e.g., the body, as in the original implementation, while enumerations can only accommodate constant Values with associated names and IDs.

There is one other benefit of using Options with for comprehensions, automatic removal of None elements from comprehensions, under most conditions (refer to [Pollak2007] and [Spiewak2009c]). Consider this first version of a script that uses Options in a for comprehension:

// code-examples/AppDesign/options-nulls/option-for-comp-v1-script.scala

case class User(userName: String, name: String, email: String, bio: String)

val newUserProfiles = List(
  Map("userName" -> "twitspam", "name" -> "Twit Spam"),
  Map("userName" -> "bucktrends", "name" -> "Buck Trends",
      "email" -> "[email protected]", "bio" -> "World's greatest bloviator"),
  Map("userName" -> "lonelygurl", "name" -> "Lonely Gurl",
      "bio" -> "Obviously fake..."),
  Map("userName" -> "deanwampler", "name" -> "Dean Wampler",
      "email" -> "[email protected]", "bio" -> "Scala passionista"),
  Map("userName" -> "al3x", "name" -> "Alex Payne",
      "email" -> "[email protected]", "bio" -> "Twitter API genius"))

// Version #1

var validUsers = for {
  user     <- newUserProfiles
  if (user.contains("userName") && user.contains("name") &&   // #1
      user.contains("email") && user.contains("bio"))         // #1
  userName <- user get "userName"
  name     <- user get "name"
  email    <- user get "email"
  bio      <- user get "bio" }
    yield User(userName, name, email, bio)

validUsers.foreach (user => println(user))

Imagine this code is used in some sort of social networking site. New users submit profile data, which is passed to this service in bulk for processing. For example, we hardcoded a list of submitted profiles, where each profile data set is a map. The map might have been copied from an HTTP session.

The service filters out incomplete profiles (missing fields), shown with the #1 comments, and creates new user objects from the complete profiles.

Running the script prints out three new users from the five submitted profiles:

User(bucktrends,Buck Trends,[email protected],World's greatest bloviator)
User(deanwampler,Dean Wampler,[email protected],Scala passionista)
User(al3x,Alex Payne,[email protected],Twitter API genius)

Now, delete the two lines with the #1 comment:

...
var validUsers = for {
  user     <- newUserProfiles
  userName <- user get "userName"
  name     <- user get "name"
  email    <- user get "email"
  bio      <- user get "bio" }
    yield User(userName, name, email, bio)

validUsers.foreach (user => println(user))

Before you rerun the script, what do you expect to happen? Will it print five lines with some fields empty (or containing other kinds of values)?

It prints the same thing! How did it do the filtering we wanted without the explicit conditional?

The answer lies in the way that for comprehensions are implemented. Here are a couple of simple for comprehensions followed by their translations (see [ScalaSpec2009]). First, we’ll look at a single generator with a yield:

for (p1 <- e1) yield e2          // for comprehension

e1 map ( case p1 => e2 )         // translation

Here’s the translation of a single generator followed by an arbitrary expression (which could be several expressions in braces, etc.):

for (p1 <- e1) e2                // for comprehension

e1 foreach ( case p1 => e2 )     // translation

With more than one generator, map is replaced with flatMap in the yield expressions, but foreach is unchanged:

for (p1 <- e1; p2 <- e2 ...) yield eN       // for comprehension

e1 flatMap ( case p1 => for (p2 <- e2 ...) yield eN )  // translation

for (p1 <- e1; p2 <- e2 ...) eN             // for comprehension

e1 foreach ( case p1 => for (p2 <- e2 ...) eN )       // translation

Note that the second through the N^th generators become nested for comprehensions that need translating.

There are similar translations for conditional statements (which become calls to filter) and val assignments. We won’t show them here, since our primary purpose is to describe just enough of the implementation details so you can understand how Options and for comprehensions work together. The additional details are described in [ScalaSpec2009], with examples.

If you follow this translation process on our example, you get the following expansion:

var validUsers = newUserProfiles flatMap {
  case user => user.get("userName") flatMap {
    case userName => user.get("name") flatMap {
      case name => user.get("email") flatMap {
        case email => user.get("bio") map {
          case bio => User(name, userName, email, bio)    // #1
        }
      }
    }
  }
}

Note that we have flatMap calls until the most nested case, where map is used (flatMap and map behave equivalently in this case).

Now we can understand why the big conditional was unnecessary. Recall that user is a Map and user.get("...") returns an Option, either None or Some(value). The key is the behavior of flatMap defined on Option, which lets us treat Options like other collections. Here is the definition of flatMap:

def flatMap[B](f: A => Option[B]): Option[B] =
  if (isEmpty) None else f(this.get)

If user.get("...") returns None, then flatMap simply returns None and never evaluates the function literal. Hence, the nested iterations simply stop and never get to the line marked with the comment #1, where the User is created.

The outermost flatMap is on the input List, newUserProfiles. On a multi-element collection like this, the behavior of flatMap is similar to map, but it flattens the new collection and doesn’t require the resulting map to have the same number of elements as the original collection, like map does.

Finally, recall from Partial Functions that the case user => ... statements, for example, cause the compiler to generate a PartialFunction to pass to flatMap and map, so no corresponding foo match {...} style wrappers are necessary.

We saw in Visibility Rules that Scala provides more fine-grained visibility rules than most other languages. You can control the visibility of types and methods outside type and package boundaries.

Consider the following example of a component in package encodedstring:

// code-examples/AppDesign/abstractions/encoded-string.scala

package encodedstring {

  trait EncodedString {
    protected[encodedstring] val string: String
    val separator: EncodedString.Separator.Delimiter

    override def toString = string

    def toTokens = string.split(separator.toString).toList
  }

  object EncodedString {
    object Separator extends Enumeration {
      type Delimiter = Value
      val COMMA = Value(",")
      val TAB   = Value("	")
    }

    def apply(s: String, sep: Separator.Delimiter) = sep match {
      case Separator.COMMA => impl.CSV(s)
      case Separator.TAB   => impl.TSV(s)
    }

    def unapply(es: EncodedString) = Some(Pair(es.string, es.separator))
  }

  package impl {
    private[encodedstring] case class CSV(override val string: String)
        extends EncodedString {
      override val separator = EncodedString.Separator.COMMA
    }

    private[encodedstring] case class TSV(override val string: String)
        extends EncodedString {
      override val separator = EncodedString.Separator.TAB
    }
  }
}

This example encapsulates handling of strings encoding comma-separated values (CSVs) or tab-separated values (TSVs). The encodedstring package exposes a trait EncodedString that is visible to clients. The concrete classes implementing CSVs and TSVs are declared private[encodedstring] in the encodedstring.impl package. The trait defines two abstract val fields: one to hold the encoded string, which is protected from client access, and the other to hold the separator (e.g., a comma). Recall from Chapter 6 that abstract fields, like abstract types and methods, must be initialized in concrete instances. In this case, string will be defined through a concrete constructor, and the separator is defined explicitly in the concrete classes, CSV and TSV.

The toString method on EncodedString prints the string as a “normal” string. By hiding the string value and the concrete classes, we have complete freedom in how the string is actually stored. For example, for extremely large strings, we might want to split them on the delimiter and store the tokens in a data structure. This could save space if the strings are large enough and we can share tokens between strings. Also, we might find this storage useful for various searching, sorting, and other manipulation tasks. All these implementation issues are transparent to the client.

The package also exposes an object with an Enumeration for the known separators, an apply factory method to construct new encoded strings, and an unapply extractor method to decompose the encoded string into its enclosed string and the delimiter. In this case, the unapply method looks trivial, but if we stored the strings in a different way, this method could transparently reconstitute the original string.

So, clients of this component only know about the EncodedString abstraction and the enumeration representing the supported types of encoded strings. All the actual implementation types and details are private to the encodedstring package. (We put them in the same file for convenience, but normally you would kept them separate.) Hence, the boundary is clear between the exposed abstractions and the internal implementation details.

The following script demonstrates the component in use:

// code-examples/AppDesign/abstractions/encoded-string-script.scala

import encodedstring._
import encodedstring.EncodedString._

def p(s: EncodedString) = {
  println("EncodedString: " + s)
  s.toTokens foreach (x => println("token: " + x))
}

val csv = EncodedString("Scala,is,great!", Separator.COMMA)
val tsv = EncodedString("Scala	is	great!", Separator.TAB)

p(csv)
p(tsv)

println( "
Extraction:" )
List(csv, "ProgrammingScala", tsv, 3.14159) foreach {
  case EncodedString(str, delim) =>
    println( "EncodedString: "" + str + "", delimiter: "" + delim + """ )
  case s: String => println( "String: " + s )
  case x => println( "Unknown Value: " + x )
}

It produces the following output:

EncodedString: Scala,is,great!
token: Scala
token: is
token: great!
EncodedString: Scala    is      great!
token: Scala
token: is
token: great!

Extraction:
EncodedString: "Scala,is,great!", delimiter: ","
String: ProgrammingScala
EncodedString: "Scala   is      great!", delimiter: "   "
Unknown Value: 3.14159

However, if we try to use the CSV class directly, for example, we get the following error:

scala> import encodedstring._
import encodedstring._

scala> val csv = impl.CSV("comma,separated,values")
<console>:6: error: object CSV cannot be accessed in package encodedstring.impl
       val csv = impl.CSV("comma,separated,values")
                      ^

scala>

In this simple example, it wasn’t essential to make the concrete types private to the component. However, we have a very minimal interface to clients of the component, and we are free to modify the implementation as we see fit with little risk of forcing client code modifications. A common cause of maintenance paralysis in mature applications is the presence of too many dependencies between concrete types, which become difficult to modify since they force changes to client code. So, for larger, more sophisticated components, this clear separation of abstraction from implementation can keep the code maintainable and reusable for a long time.

We saw in Chapter 4 how traits promote mixin composition. A class can focus on its primary domain, and other responsibilities can be implemented separately in traits. When instances are constructed, classes and traits can be combined to compose the full range of required behaviors.

For example, in Overriding Abstract Types, we discussed our second version of the Observer Pattern:

// code-examples/AdvOOP/observer/observer2.scala

package observer

trait AbstractSubject {
  type Observer

  private var observers = List[Observer]()
  def addObserver(observer:Observer) = observers ::= observer
  def notifyObservers = observers foreach (notify(_))

  def notify(observer: Observer): Unit
}

trait SubjectForReceiveUpdateObservers extends AbstractSubject {
  type Observer = { def receiveUpdate(subject: Any) }

  def notify(observer: Observer): Unit = observer.receiveUpdate(this)
}

trait SubjectForFunctionalObservers extends AbstractSubject {
  type Observer = (AbstractSubject) => Unit

  def notify(observer: Observer): Unit = observer(this)
}

We used this version to observe button “clicks” in a UI. Let’s revisit this implementation and resolve a few limitations, using our next tool for scalable abstractions, self-type annotations combined with abstract type members.

There are a few things that are unsatisfying about the implementation of AbstractSubject in our second version of the Observer Pattern. The first occurs in SubjectForReceiveUpdateObservers, where the Observer type is defined to be the structural type { def receiveUpdate(subject: Any) }. It would be nice to narrow the type of subject to something more specific than Any.

The second issue, which is really the same problem in a different form, occurs in SubjectForFunctionalObservers, where the Observer type is defined to be the type (AbstractSubject) => Unit. We would like the argument to the function to be something more specific than AbstractSubject. Perhaps this drawback wasn’t so evident before, because our simple examples never needed to access Button state information or methods.

In fact, we expect the actual types of the subject and observer to be specialized covariantly. For example, when we’re observing Buttons, we expect our observers to be specialized for Buttons, so they can access Button state and methods. This covariant specialization is sometimes called family polymorphism (see [Odersky2005]). Let’s fix our design to support this covariance.

To simplify the example, let’s focus on just the receiveUpdate form of the Observer, which we implemented with SubjectForReceiveUpdateObservers before. Here is a reworking of our pattern, loosely following an example in [Odersky2005]. (Note that the Scala syntax has changed somewhat since that paper was written.)

// code-examples/AppDesign/abstractions/observer3-wont-compile.scala
// WON'T COMPILE

package observer

abstract class SubjectObserver {
  type S <: Subject
  type O <: Observer

  trait Subject {
    private var observers = List[O]()
    def addObserver(observer: O) = observers ::= observer
    def notifyObservers = observers foreach (_.receiveUpdate(this)) // ERROR
  }

  trait Observer {
    def receiveUpdate(subject: S)
  }
}

We’ll explain the error in a minute. Note how the types S and O are declared. As we saw in Understanding Parameterized Types, the expression type S <: Subject defines an abstract type S where the only allowed concrete types will be subtypes of Subject. The declaration of O is similar. To be clear, S and O are “placeholders” at this point, while Subject and Observer are abstract traits defined in SubjectObserver.

By the way, declaring SubjectObserver as an abstract class versus a trait is somewhat arbitrary. We’ll derive concrete objects from it shortly. We need SubjectObserver primarily so we have a type to “hold” our abstract type members S and O.

However, if you attempt to compile this code as currently written, you get the following error:

... 10: error: type mismatch;
 found   : SubjectObserver.this.Subject
 required: SubjectObserver.this.S
      def notifyObservers = observers foreach (_.receiveUpdate(this))
                                                               ^
one error found

In the nested Observer trait, receiveUpdate is expecting an instance of type S, but we are passing it this, which is of type Subject. In other words, we are passing an instance of a parent type of the type expected. One solution would be to change the signature to just expect the parent type, Subject. That’s undesirable. We just mentioned that our concrete observers need the more specific type, the actual concrete type we’ll eventually define for S, so they can call methods on it. For example, when observing UI CheckBoxes, the observers will want to read whether or not a box is checked. We don’t want to force the observers to use unsafe casts.

We looked at composition using self-type annotations in Self-Type Annotations. Let’s use this feature now to solve our current compilation problem. Here is the same code again with a self-type annotation:

// code-examples/AppDesign/abstractions/observer3.scala

package observer

abstract class SubjectObserver {
  type S <: Subject
  type O <: Observer

  trait Subject {
    self: S =>    // #1
    private var observers = List[O]()
    def addObserver(observer: O) = observers ::= observer
    def notifyObservers = observers foreach (_.receiveUpdate(self))  // #2
  }

  trait Observer {
    def receiveUpdate(subject: S)
  }
}

Comment #1 shows the self-type annotation, self: S =>. We can now use self as an alias for this, but whenever it appears, the type will be assumed to be S, not Subject. It is as if we’re telling Subject to impersonate another type, but in a type-safe way, as we’ll see.

Actually, we could have used this instead of self in the annotation, but self is somewhat conventional. A different name also reminds us that we’re working with a different type.

Are self-type annotations a safe thing to use? When an actual concrete SubjectObserver is defined, S and O will be specified and type checking will be performed to ensure that the concrete S and O are compatible with Subject and Observer. In this case, because we also defined S to be a subtype of Subject and O to be a subtype of Observer, any concrete types derived from Subject and Observer, respectively, will work.

Comment #2 shows that we pass self instead of this to receiveUpdate.

Now that we have a generic implementation of the pattern, let’s specialize it for observing button clicks:

// code-examples/AppDesign/abstractions/button-observer3.scala

package ui
import observer._

object ButtonSubjectObserver extends SubjectObserver {
  type S = ObservableButton
  type O = ButtonObserver

  class ObservableButton(name: String) extends Button(name) with Subject {
    override def click() = {
      super.click()
      notifyObservers
    }
  }

  trait ButtonObserver extends Observer {
    def receiveUpdate(button: ObservableButton)
  }
}

We declare an object ButtonSubjectObserver where we define S and O to be ObservableButton and ButtonObserver, respectively, both of which are defined in the object. We use an object now so that we can refer to the nested types easily, as we’ll see shortly.

ObservableButton is a concrete class that overrides click to notify observers, similar to our previous implementations in Chapter 4. However, ButtonObserver is still an abstract trait, because receiveUpdate is not defined. Notice that the argument to receiveUpdate is now an ObservableButton, the value assigned to S.

The final piece of the puzzle is to define a concrete observer. As before, we’ll count button clicks. However, to emphasize the value of having the specific type of instance passed to the observer, a Button in this case, we’ll enhance the observer to track clicks for multiple buttons using a hash map with the button labels as the keys. No type casts are required!

// code-examples/AppDesign/abstractions/button-click-observer3.scala

package ui
import observer._

class ButtonClickObserver extends ButtonSubjectObserver.ButtonObserver {
  val clicks = new scala.collection.mutable.HashMap[String,Int]()

  def receiveUpdate(button: ButtonSubjectObserver.ObservableButton) = {
    val count = clicks.getOrElse(button.label, 0) + 1
    clicks.update(button.label, count)
  }
}

Every time ButtonClickObserver.receiveUpdate is called, it fetches the current count for the button, if any, and updates the map with an incremented count. Note that it is now impossible to call receiveUpdate with a normal Button. We have to use an ObservableButton. This restriction eliminates bugs where we don’t get the notifications we expected. We also have access to any “enhanced” features that ObservableButton may have.

Finally, here is a specification that exercises the code:

// code-examples/AppDesign/abstractions/button-observer3-spec.scala

package ui
import org.specs._
import observer._

object ButtonObserver3Spec extends Specification {
  "An Observer counting button clicks" should {
    "see all clicks" in {
      val button1 = new ButtonSubjectObserver.ObservableButton("button1")
      val button2 = new ButtonSubjectObserver.ObservableButton("button2")
      val button3 = new ButtonSubjectObserver.ObservableButton("button3")
      val buttonObserver = new ButtonClickObserver
      button1.addObserver(buttonObserver)
      button2.addObserver(buttonObserver)
      button3.addObserver(buttonObserver)
      clickButton(button1, 1)
      clickButton(button2, 2)
      clickButton(button3, 3)
      buttonObserver.clicks("button1") mustEqual 1
      buttonObserver.clicks("button2") mustEqual 2
      buttonObserver.clicks("button3") mustEqual 3
    }
  }

  def clickButton(button: Button, nClicks: Int) =
    for (i <- 1 to nClicks)
      button.click()
}

We create three buttons and one observer for all of them. We then click the buttons different numbers of times. Finally, we confirm that the clicks were properly counted for each button.

We see again how abstract types combined with self-type annotations provide a reusable abstraction that is easy to extend in a type-safe way for particular needs. Even though we defined a general protocol for observing an “event” after it happened, we were able to define subtypes specific to Buttons without resorting to unsafe casts from Subject abstractions.

The Scala compiler itself is implemented using these mechanisms (see [Odersky2005]) to make it modular in useful ways. For example, it is relatively straightforward to implement compiler plugins.

We’ll revisit these idioms in Dependency Injection in Scala: The Cake Pattern.

The Visitor Pattern solves the problem of adding a new operation to a class hierarchy without editing the source code for the classes in the hierarchy. For a number of practical reasons, it may not be feasible or desirable to edit the hierarchy to support the new operation.

Let’s look at an example of the pattern using the Shape class hierarchy we have used previously. We’ll start with the case class version from Case Classes:

// code-examples/AdvOOP/shapes/shapes-case.scala

package shapes {
  case class Point(x: Double, y: Double)

  abstract class Shape() {
    def draw(): Unit
  }

  case class Circle(center: Point, radius: Double) extends Shape() {
    def draw() = println("Circle.draw: " + this)
  }

  case class Rectangle(lowerLeft: Point, height: Double, width: Double)
      extends Shape() {
    def draw() = println("Rectangle.draw: " + this)
  }

  case class Triangle(point1: Point, point2: Point, point3: Point)
      extends Shape() {
    def draw() = println("Triangle.draw: " + this)
  }
}

Suppose we don’t want the draw method in the classes. This is a reasonable design choice, since the drawing method will be highly dependent on the particular context of use, such as details of the graphics libraries on the platforms the application will run on. For greater reusability, we would like drawing to be an operation we decouple from the shapes themselves.

First, we refactor the Shape hierarchy to support the Visitor Pattern, following the example in [GOF1995]:

// code-examples/AppDesign/patterns/shapes-visitor.scala

package shapes {
  trait ShapeVisitor {
    def visit(circle: Circle): Unit
    def visit(rect: Rectangle): Unit
    def visit(tri: Triangle): Unit
  }

  case class Point(x: Double, y: Double)

  sealed abstract class Shape() {
    def accept(visitor: ShapeVisitor): Unit
  }

  case class Circle(center: Point, radius: Double) extends Shape() {
    def accept(visitor: ShapeVisitor) = visitor.visit(this)
  }

  case class Rectangle(lowerLeft: Point, height: Double, width: Double)
        extends Shape() {
    def accept(visitor: ShapeVisitor) = visitor.visit(this)
  }

  case class Triangle(point1: Point, point2: Point, point3: Point)
        extends Shape() {
    def accept(visitor: ShapeVisitor) = visitor.visit(this)
  }
}

We define a ShapeVisitor trait, which has one method for each concrete class in the hierarchy, e.g., visit(circle: Circle). Each such method takes one parameter of the corresponding type to visit. Concrete derived classes will implement each method to do the appropriate operation for the particular type passed in.

The Visitor Pattern requires a one-time modification to the class hierarchy. An overridden method named accept must be added, which takes a Visitor parameter. This method must be overridden for each class. It calls the corresponding method defined on the visitor instance, passing this as the argument.

Finally, note that we declared Shape to be sealed. It won’t help us prevent some bugs in the Visitor Pattern implementation, but it will prove useful shortly.

Here is a concrete visitor that supports our original draw operation:

// code-examples/AppDesign/patterns/shapes-drawing-visitor.scala

package shapes {
  class ShapeDrawingVisitor extends ShapeVisitor {
    def visit(circle: Circle): Unit =
      println("Circle.draw: " + circle)

    def visit(rect: Rectangle): Unit =
      println("Rectangle.draw: " + rect)

    def visit(tri: Triangle): Unit =
      println("Triangle.draw: " + tri)
  }
}

For each visit method, it “draws” the Shape instance appropriately. Finally, here is a script that exercises the code:

// code-examples/AppDesign/patterns/shapes-drawing-visitor-script.scala

import shapes._

val p00 = Point(0.0, 0.0)
val p10 = Point(1.0, 0.0)
val p01 = Point(0.0, 1.0)

val list = List(Circle(p00, 5.0),
                Rectangle(p00, 2.0, 3.0),
                Triangle(p00, p10, p01))

val shapesDrawer = new ShapeDrawingVisitor
list foreach { _.accept(shapesDrawer) }

It produces the following output:

Circle.draw: Circle(Point(0.0,0.0),5.0)
Rectangle.draw: Rectangle(Point(0.0,0.0),2.0,3.0)
Triangle.draw: Triangle(Point(0.0,0.0),Point(1.0,0.0),Point(0.0,1.0))

Visitor has been criticized for being somewhat inelegant and for breaking the Open-Closed Principle (OCP; see [Martin2003]), because if the hierarchy changes, you are forced to edit (and test and redeploy) all the visitors for that hierarchy. Note that every ShapeVisitor trait has methods that hardcode information about every Shape derived type. These kinds of changes are also error-prone.

In languages with “open types,” like Ruby, an alternative to the Visitor Pattern is to create a new source file that reopens all the types in the hierarchy and inserts an appropriate method implementation in each one. No modifications to the original source code are required.

Scala does not support open types, of course, but it offers a few alternatives. The first approach we’ll discuss combines pattern matching with implicit conversions. Let’s begin by refactoring the ShapeVisitor code to remove the Visitor Pattern logic:

// code-examples/AppDesign/patterns/shapes.scala

package shapes2 {
  case class Point(x: Double, y: Double)

  sealed abstract class Shape()

  case class Circle(center: Point, radius: Double) extends Shape()

  case class Rectangle(lowerLeft: Point, height: Double, width: Double)
      extends Shape()

  case class Triangle(point1: Point, point2: Point, point3: Point)
      extends Shape()
}

If we would like to invoke draw as a method on any Shape, then we will have to use an implicit conversion to a wrapper class with the draw method:

// code-examples/AppDesign/patterns/shapes-drawing-implicit.scala

package shapes2 {
  class ShapeDrawer(val shape: Shape) {
    def draw = shape match {
      case c: Circle    => println("Circle.draw: " + c)
      case r: Rectangle => println("Rectangle.draw: " + r)
      case t: Triangle  => println("Triangle.draw: " + t)
    }
  }

  object ShapeDrawer {
    implicit def shape2ShapeDrawer(shape: Shape) = new ShapeDrawer(shape)
  }
}

Instances of ShapeDrawer hold a Shape object. When draw is called, the shape is pattern matched based on its type to determine the appropriate way to draw it.

A companion object declares an implicit conversion that wraps a Shape in a ShapeDrawer.

This script exercises the code:

// code-examples/AppDesign/patterns/shapes-drawing-implicit-script.scala

import shapes2._

val p00 = Point(0.0, 0.0)
val p10 = Point(1.0, 0.0)
val p01 = Point(0.0, 1.0)

val list = List(Circle(p00, 5.0),
                Rectangle(p00, 2.0, 3.0),
                Triangle(p00, p10, p01))

import shapes2.ShapeDrawer._

list foreach { _.draw }

It produces the same output as the example using the Visitor Pattern.

This implementation of ShapeDrawer has some similarities with the Visitor Pattern, but it is more concise, elegant, and requires no code modifications to the original Shape hierarchy.

Technically, the implementation has the same OCP issue as the Visitor Pattern. Changing the Shape hierarchy requires a change to the pattern matching expression. However, the required changes are isolated to one place and they are more succinct. In fact, all the logic for drawing is now contained in one place, rather than separated into draw methods in each Shape class and potentially scattered across different files. Note that because we sealed the hierarchy, a compilation error in draw will occur if we forget to change it when the hierarchy changes.

If we don’t like the pattern matching in the draw method, we could implement a separate “drawer” class and a separate implicit conversion for each Shape class. That would allow us to keep each shape drawing operation in a separate file, for modularity, with the drawback of more code and files to manage.

If, on the other hand, we don’t care about using the object-oriented shape.draw syntax, we could eliminate the implicit conversion and do the same pattern matching that is done in ShapeDrawer.draw. This approach could be simpler, especially when the extra behavior can be isolated to one place. Indeed, this approach would be a conventional functional approach, as illustrated in the following script:

// code-examples/AppDesign/patterns/shapes-drawing-pattern-script.scala

import shapes2._

val p00 = Point(0.0, 0.0)
val p10 = Point(1.0, 0.0)
val p01 = Point(0.0, 1.0)

val list = List(Circle(p00, 5.0),
                Rectangle(p00, 2.0, 3.0),
                Triangle(p00, p10, p01))

val drawText = (shape:Shape) => shape match {
  case circle: Circle =>  println("Circle.draw: " + circle)
  case rect: Rectangle => println("Rectangle.draw: " + rect)
  case tri: Triangle =>   println("Triangle.draw: " + tri)
}

def pointToXML(point: Point) =
  "<point><x>%.1f</x><y>%.1f</y></point>".format(point.x, point.y)

val drawXML = (shape:Shape) => shape match {
  case circle: Circle =>  {
    println("<circle>")
    println("  <center>" + pointToXML(circle.center) + "</center>")
    println("  <radius>" + circle.radius + "</radius>")
    println("</circle>")
  }
  case rect: Rectangle => {
    println("<rectangle>")
    println("  <lower-left>" + pointToXML(rect.lowerLeft) + "</lower-left>")
    println("  <height>" + rect.height + "</height>")
    println("  <width>" + rect.width + "</width>")
    println("</rectangle>")
  }
  case tri: Triangle => {
    println("<triangle>")
    println("  <point1>" + pointToXML(tri.point1) + "</point1>")
    println("  <point2>" + pointToXML(tri.point2) + "</point2>")
    println("  <point3>" + pointToXML(tri.point3) + "</point3>")
    println("</triangle>")
  }
}

list foreach (drawText)
println("")
list foreach (drawXML)

We define two function values and assign them to variables, drawText and drawXML, respectively. Each drawX function takes an input Shape, pattern matches it to the correct type, and “draws” it appropriately. We also define a helper method to convert a Point to XML in the format we want.

Finally, we loop through the list of shapes twice. The first time, we pass drawText as the argument to foreach. The second time, we pass drawXML. Running this script reproduces the previous results for “text” output, followed by new XML output:

Circle.draw: Circle(Point(0.0,0.0),5.0)
Rectangle.draw: Rectangle(Point(0.0,0.0),2.0,3.0)
Triangle.draw: Triangle(Point(0.0,0.0),Point(1.0,0.0),Point(0.0,1.0))

<circle>
  <center><point><x>0.0</x><y>0.0</y></point></center>
  <radius>5.0</radius>
</circle>
<rectangle>
  <lower-left><point><x>0.0</x><y>0.0</y></point></lower-left>
  <height>2.0</height>
  <width>3.0</width>
</rectangle>
<triangle>
  <point1><point><x>0.0</x><y>0.0</y></point></point1>
  <point2><point><x>1.0</x><y>0.0</y></point></point2>
  <point3><point><x>0.0</x><y>1.0</y></point></point3>
</triangle>

Any of these idioms provides a powerful way to add additional, special-purpose functionality that may not be needed “everywhere” in the application. It’s a great way to remove methods from objects that don’t absolutely have to be there.

A drawing application should only need to know how to do input and output of shapes in one place, whether it is serializing shapes to a textual format for storage or rendering shapes to the screen. We can separate the drawing “concern” from the rest of the functionality for shapes, and we can isolate the logic for drawing, all without modifying the Shape hierarchy or any of the places where it is used in the application. The Visitor Pattern gives us some of this separation and isolation, but we are required to add visitor implementation logic to each Shape.

Let’s conclude with a discussion of one other option that may be applicable in some contexts. If you have complete control over how shapes are constructed, e.g., through a single factory, you can modify the factory to mix in traits that add new behaviors as needed:

// code-examples/AppDesign/patterns/shapes-drawing-factory.scala

package shapes2 {
  trait Drawing {
    def draw: Unit
  }

  trait CircleDrawing extends Drawing {
    def draw = println("Circle.draw " + this)
  }
  trait RectangleDrawing extends Drawing {
    def draw = println("Rectangle.draw: " + this)
  }
  trait TriangleDrawing extends Drawing {
    def draw = println("Triangle.draw: " + this)
  }

  object ShapeFactory {
    def makeShape(args: Any*) = args(0) match {
      case "circle" => {
        val center = args(1).asInstanceOf[Point]
        val radius = args(2).asInstanceOf[Double]
        new Circle(center, radius) with CircleDrawing
      }
      case "rectangle" => {
        val lowerLeft = args(1).asInstanceOf[Point]
        val height    = args(2).asInstanceOf[Double]
        val width     = args(3).asInstanceOf[Double]
        new Rectangle(lowerLeft, height, width) with RectangleDrawing
      }
      case "triangle" => {
        val p1 = args(1).asInstanceOf[Point]
        val p2 = args(2).asInstanceOf[Point]
        val p3 = args(3).asInstanceOf[Point]
        new Triangle(p1, p2, p3) with TriangleDrawing
      }
      case x => throw new IllegalArgumentException("unknown: " + x)
    }
  }
}

We define a Drawing trait and concrete derived traits for each Shape class. Then we define a ShapeFactory object with a makeShape factory method that takes a variable-length list of arguments. A match is done on the first argument to determine which shape to make. The trailing arguments are cast to appropriate types to construct each shape, with the corresponding drawing trait mixed in. A similar factory could be written for adding draw methods that output XML. (The variable-length list of Any values, heavy use of casting, and minimal error checking were done for expediency. A real implementation could minimize these “hacks.”)

The following script exercises the factory:

// code-examples/AppDesign/patterns/shapes-drawing-factory-script.scala

import shapes2._

val p00 = Point(0.0, 0.0)
val p10 = Point(1.0, 0.0)
val p01 = Point(0.0, 1.0)

val list = List(
    ShapeFactory.makeShape("circle", p00, 5.0),
    ShapeFactory.makeShape("rectangle", p00, 2.0, 3.0),
    ShapeFactory.makeShape("triangle", p00, p10, p01))

list foreach { _.draw }

Compared to our previous scripts, the list of shapes is now constructed using the factory. When we want to draw the shapes in the foreach statement, we simply call draw on each shape. As before, the output is the following:

Circle.draw Circle(Point(0.0,0.0),5.0)
Rectangle.draw: Rectangle(Point(0.0,0.0),2.0,3.0)
Triangle.draw: Triangle(Point(0.0,0.0),Point(1.0,0.0),Point(0.0,1.0))

There is one subtlety with this approach that we should discuss. Notice that the script never assigns the result of a ShapeFactory.makeShape call to a Shape variable. If it did that, it would not be able to call draw on the instance!

In this script, Scala inferred a slightly different common supertype for the parameterized list. You can see that type if you use the :load command to load the script while inside the interactive scala interpreter, as in the following session:

$ scala -cp ...
Welcome to Scala version 2.8.0.final (Java ...).
Type in expressions to have them evaluated.
Type :help for more information.

scala> :load design-patterns/shapes-drawing-factory-script.scala
Loading design-patterns/shapes-drawing-factory-script.scala...
import shapes2._
p00: shapes2.Point = Point(0.0,0.0)
p10: shapes2.Point = Point(1.0,0.0)
p01: shapes2.Point = Point(0.0,1.0)
list: List[Product with shapes2.Shape with shapes2.Drawing] = List(...)
Circle.draw Circle(Point(0.0,0.0),5.0)
Rectangle.draw: Rectangle(Point(0.0,0.0),2.0,3.0)
Triangle.draw: Triangle(Point(0.0,0.0),Point(1.0,0.0),Point(0.0,1.0))

scala>

Notice the line that begins list: List[Product with shapes2.Shape with shapes2.Drawing]. This line was printed after the list of shapes was parsed. The inferred common supertype is Product with shapes2.Shape with shapes2.Drawing. Product is a trait mixed into all case classes, such as our concrete subclasses of Shape. Recall that to avoid case-class inheritance, Shape itself is not a case class. (See Case Classes for details on why case class inheritance should be avoided.) So, our common supertype is an anonymous class that incorporates Shape, Product, and the Drawing trait.

If you want to assign one of these drawable shapes to a variable and still be able to invoke draw, use a declaration like the following (shown as a continuation of the same interactive scala session):

scala> val s: Shape with Drawing = ShapeFactory.makeShape("circle", p00, 5.0)
s: shapes2.Shape with shapes2.Drawing = Circle(Point(0.0,0.0),5.0)

scala> s.draw
Circle.draw Circle(Point(0.0,0.0),5.0)

scala>

Dependency injection (DI), a form of inversion of control (IoC), is a powerful technique for resolving dependencies between “components” in larger applications. It supports minimizing the coupling between these components, so it is relatively easy to substitute different components for different circumstances.

It used to be that when a client object needed a database “accessor” object, for example, it would just instantiate the accessor itself. While convenient, this approach makes unit testing very difficult because you have to test with a real database. It also compromises reuse, for those alternative situations where another persistence mechanism (or none) is required. Inversion of control solves this problem by reversing responsibility for satisfying the dependency between the object and the database connection.

An example of IoC is JNDI. Instead of instantiating an accessor object, the client object asks JDNI to provide one. The client doesn’t care what actual type of accessor is returned. Hence, the client object is no longer coupled to a concrete implementation of the dependency. It only depends on an appropriate abstraction of a persistence accessor, i.e., a Java interface or Scala trait.

Dependency injection takes IoC to its logical conclusion. Now the object does nothing to resolve the dependency. Instead, an external mechanism with system-wide knowledge “injects” the appropriate accessor object using a constructor argument or a setter method. This happens when the client is constructed. DI eliminates dependencies on IoC mechanisms in code (e.g., no more JNDI calls) and keeps objects relatively simple, with minimal coupling to other objects.

Back to unit testing, it is preferable to use a test double for heavyweight dependencies to minimize the overhead and other complications of testing. Our client object with a dependency on a database accessor object is a classic example. While unit testing the client, the overhead and complications of using a real database are prohibitive. Using a lightweight test double with hardcoded sample data provides simpler setup and tear down, faster execution, and predictable behavior from the data accessor dependency.

In Java, DI is usually done using an inversion of control container, like the Spring Framework ([SpringFramework]), or a Java-API equivalent like Google’s Guice API (see [Guice]). These options can be used with Scala code, especially when you are introducing Scala into a mature Java environment.

However, Scala offers some unique options for implementing DI in Scala code, which are discussed by [Bonér2008b]. We’ll discuss one of them, the Cake Pattern, which can replace or complement these other dependency injection mechanisms. We’ll see that it is similar to the implementation of the Observer Pattern we discussed earlier in this chapter, in Self-Type Annotations and Abstract Type Members. The Cake Pattern was described by [Odersky2005], although it was given that name after that paper was published. [Bonér2008b] also discusses alternatives.

Let’s build a simple component model for an overly simplified Twitter client. We want a configurable UI, a configurable local cache of past tweets, and a configurable connection to the Twitter service itself. Each of these “components” will be specified separately, along with a client component that will function as the “middleware” that ties the application together. The client component will depend on the other components. When we create a concrete client, we’ll configure in the concrete pieces of the other components that we need:

// code-examples/AppDesign/dep-injection/twitter-client.scala

package twitterclient
import java.util.Date
import java.text.DateFormat

class TwitterUserProfile(val userName: String) {
  override def toString = "@" + userName
}

case class Tweet(
  val tweeter: TwitterUserProfile,
  val message: String,
  val time: Date) {

  override def toString = "(" +
    DateFormat.getDateInstance(DateFormat.FULL).format(time) + ") " +
    tweeter + ": " + message
}

trait Tweeter {
  def tweet(message: String)
}

trait TwitterClientUIComponent {
  val ui: TwitterClientUI

  abstract class TwitterClientUI(val client: Tweeter) {
    def sendTweet(message: String) = client.tweet(message)
    def showTweet(tweet: Tweet): Unit
  }
}

trait TwitterLocalCacheComponent {
  val localCache: TwitterLocalCache

  trait TwitterLocalCache {
    def saveTweet(tweet: Tweet): Unit
    def history: List[Tweet]
  }
}

trait TwitterServiceComponent {
  val service: TwitterService

  trait TwitterService {
    def sendTweet(tweet: Tweet): Boolean
    def history: List[Tweet]
  }
}

trait TwitterClientComponent {
  self: TwitterClientUIComponent with
        TwitterLocalCacheComponent with
        TwitterServiceComponent =>

  val client: TwitterClient

  class TwitterClient(val user: TwitterUserProfile) extends Tweeter {
    def tweet(msg: String) = {
      val twt = new Tweet(user, msg, new Date)
      if (service.sendTweet(twt)) {
        localCache.saveTweet(twt)
        ui.showTweet(twt)
      }
    }
  }
}

The first class, TwitterUserProfile, encapsulates a user’s profile, which we limit to the username. The second class is a case class, Tweet, that encapsulates a single “tweet” (a Twitter message, limited to 140 characters by the Twitter service). Besides the message string, it encapsulates the user who sent the tweet and the date and time when it was sent. We made this class a case class for the convenient support case classes provide for creating objects and pattern matching on them. We didn’t make the profile class a case class, because it is more likely to be used as the parent of more detailed profile classes.

Next is the Tweeter trait that declares one method, tweet. This trait is defined solely to eliminate a potential circular dependency between two components, TwitterClientComponent and TwitterClientUIComponent. All the components are defined next in the file.

There are four components. Note that they are implemented as traits:

They all have a similar structure. Each one declares a nested trait or class that encapsulates the component’s behavior. Each one also declares a val with one instance of the nested type.

Often in Java, packages are informally associated with components. This is common in other languages, too, using their equivalent of a package, e.g., a module or a namespace. Here we define a more precise notion of a component, and a trait is the best vehicle for it, because traits are designed for mixin composition.

TwitterClientUIComponent declares a val named ui of the nested type TwitterClientUI. This class has a client field that must be initialized with a Tweeter instance. In fact, this instance will be a TwitterClient (defined in TwitterClientComponent), which extends Tweeter.

TwitterClientUI has two methods. The first is sendTweet, which is defined to call the client object. This method would be used by the UI to call the client when the user sends a new tweet. The second method, showTweet, goes the other direction. It is called whenever a new tweet is to be displayed, e.g., from another user. It is abstract, pending the “decision” of the kind of UI to use.

Similarly, TwitterLocalCacheComponent declares TwitterLocalCache and an instance of it. Instances with this trait save tweets to the local persistent cache when saveTweet is called. You can retrieve the cached tweets with history.

TwitterServiceComponent is very similar. Its nested type has a method, sendTweet, that sends a new tweet to Twitter. It also has a history method that retrieves all the tweets for the current user.

Finally, TwitterClientComponent contains a concrete class, TwitterClient, that integrates the components. Its one tweet method sends new tweets to the Twitter service. If successful, it sends the tweet back to the UI and to the local persistent cache.

TwitterClientComponent also has the following self-type annotation:

self: TwitterClientUIComponent with
      TwitterLocalCacheComponent with
      TwitterServiceComponent =>

The effect of this declaration is to say that any concrete TwitterClientComponent must also behave like these other three components, thereby composing all the components into one client application instance. This composition will be realized by mixing in these components, which are traits, when we create concrete clients, as we will see shortly.

The self-type annotation also means we can reference the vals declared in these components. Notice how TwitterClient.tweet references the service, localCache, and the ui as if they are variables in the scope of this method. In fact, they are in scope, because of the self-type annotation.

Notice also that all the methods that call other components are concrete. Those inter-component relationships are fully specified. The abstractions are directed “outward,” toward the graphical user interface, a caching mechanism, etc.

Let’s now define a concrete Twitter client that uses a textual (command-line) UI, an in-memory local cache, and fakes the interaction with the Twitter service:

// code-examples/AppDesign/dep-injection/twitter-text-client.scala

package twitterclient

class TextClient(userProfile: TwitterUserProfile)
    extends TwitterClientComponent
    with TwitterClientUIComponent
    with TwitterLocalCacheComponent
    with TwitterServiceComponent {

  // From TwitterClientComponent:

  val client = new TwitterClient(userProfile)

  // From TwitterClientUIComponent:

  val ui = new TwitterClientUI(client) {
    def showTweet(tweet: Tweet) = println(tweet)
  }

  // From TwitterLocalCacheComponent:

  val localCache = new TwitterLocalCache {
    private var tweets: List[Tweet] = Nil

    def saveTweet(tweet: Tweet) = tweets ::= tweet

    def history = tweets
  }

  // From TwitterServiceComponent

  val service = new TwitterService() {
    def sendTweet(tweet: Tweet) = {
      println("Sending tweet to Twitter HQ")
      true
    }
    def history = List[Tweet]()
  }
}

Our TextClient concrete class extends TwitterClientComponent and mixes in the three other components. By mixing in the other components, we satisfy the self-type annotations in TwitterClientComponent. In other words, TextClient is also a TwitterClientUIComponent, a TwitterLocalCacheComponent, and a TwitterServiceComponent, in addition to being a TwitterClientComponent.

The TextClient constructor takes one argument, a user profile, which will be passed onto the nested client class.

TextClient has to define four vals, one from TwitterClientComponent and three from the other mixins. For the client, it simply creates a new TwitterClient, passing it the userProfile.

For the ui, it instantiates an anonymous class derived from TwitterClientUI. It defines showTweet to print out the tweet.

For the localCache, it instantiates an anonymous class derived from TwitterLocalCache. It keeps the history of tweets in a List.

Finally, for the service, it instantiates an anonymous class derived from TwitterService. This “fake” defines sendTweet to print out a message and to return an empty list for the history.

Let’s try our client with the following script:

// code-examples/AppDesign/dep-injection/twitter-text-client-script.scala

import twitterclient._

val client = new TextClient(new TwitterUserProfile("BuckTrends"))
client.ui.sendTweet("My First Tweet. How's this thing work?")
client.ui.sendTweet("Is this thing on?")
client.ui.sendTweet("Heading to the bathroom...")
println("Chat history:")
client.localCache.history.foreach {t => println(t)}

We instantiate a TextClient for the user “BuckTrends.” Old Buck sends three insightful tweets through the UI. We finish by reprinting the history of tweets, in reverse order, that are cached locally. Running this script yields output like the following:

Sending tweet to Twitter HQ
(Sunday, May 3, 2009) @BuckTrends: My First Tweet. How's this thing work?
Sending tweet to Twitter HQ
(Sunday, May 3, 2009) @BuckTrends: Is this thing on?
Sending tweet to Twitter HQ
(Sunday, May 3, 2009) @BuckTrends: Heading to the bathroom...
Chat history:
(Sunday, May 3, 2009) @BuckTrends: Heading to the bathroom...
(Sunday, May 3, 2009) @BuckTrends: Is this thing on?
(Sunday, May 3, 2009) @BuckTrends: My First Tweet. How's this thing work?

Your date will vary, of course. Recall that the Sending tweet to Twitter HQ line is printed by the fake service.

To recap, each major component in the Twitter client was declared in its own trait, with a nested type for the component’s fields and methods. The client component declared its dependencies on the other components through a self-type annotation. The concrete client class mixed in those components and defined each component val to be an appropriate subtype of the corresponding abstract classes and traits that were declared in the components.

We get type-safe “wiring” together of components, a flexible component model, and we did it all in Scala code! There are alternatives to the Cake Pattern for implementing dependency injection in Scala. See [Bonér2008b] for other examples.