Scala Pimp-My-Library example

Recently working on a project test there was an incompatibility of the assert keyword between ScalaTest and Scalaz. I was looking after Scalaz’s feature of invoking someĀ on any data type after import scalaz.Scalaz._

After a while I gave up and wrote it myself, surprisingly simple and concise:

class SomeType[T](t:T){
def some = Some(t)
implicit def typeToSomeType[T](t:T) = new SomeType(t)

Making possible:

scala> 123.some
res7: Some[Int] = Some(123)

res8: Some[String] = Some(hi)

Implicits is a nice way to type-safe upon compile time some global state (as long as it doesn’t become unwieldy long).

In Groovy we could achieve same effect via the MetaClass object, but without compile time type-safety as Groovy it’s a dynamic language and all the magic happens at runtime. Also we can’t use parametric polymorphism while invoking the MetaClass object (or at least I don’t know how to do it!).

groovy> String.metaClass.quote={"*"+delegate+"*"}
===> groovysh_evaluate$_run_closure1@4b51ac10
groovy:000> "hi".quote()
===> *hi*

Visitor Design Pattern in Scala

Scala provides built-in support for the Visitor Design Pattern through the use of pattern matching.

The Visitor Design Pattern is trying to address the problem of never-ending new functionality that is otherwise implemented by adding new methods in the inheritance tree.

According to the Visitor pattern the inheritance tree is decoupled from a new functionality and encapsulated in a separate object that packs all implementations according to the inheritance tree normally by using method overloading of all the various types.

In Scala by the use of the built-in pattern matching this becomes very easy:

class Animal { def walk:String }

class Dog extends Animal { override def walk = "on 4" }

class Man extends Animal { override def walk = "on 2" }

 *  Visitor Pattern provides a solution to never-ending new
 *  functionality that would otherwise be implemented with new
 *  method in the hierarchy tree.
def talk(animal: Animal) = animal match {
  case Dog => "wav wav"
  case Man => "hi"

 *  New functionality implemented in separate methods that
 *  uses pattern matching to implement tailored functionality.
def swim(animal: Animal) = animal match {
  case Dog => "on 4"
  case Man => "on 4"

Strategy Pattern in Scala – A Pragmatic Example

Let’s say we want to create a newsletter grouping together all the Daily Deals coming from popular IT Book Publishers.

We can source the Daily Deal information by web-scrapping the publisher website.

We’ll employ the Strategy Pattern as we want to encapsulate the web-scrapping algorithm that is distinct for each publisher website and we want to maintain flexibility of introducing new publishers in the future without altering the core context.

Essentially where we want to get to is a form like this:

new WebScrappingContext(Strategy).dailyDeal(url)

In the above form, the Strategy can vary and be interchangeable, paired with the publisher url that will be applied to the Strategy Functor.

Let’s start by defining a helpful type Strategy that gets a url and produces the Daily Deal:

type WebScrappingStrategy = String => String

Next we’ll create the context that would be hosting the Strategy Functor and would apply the url string on it:

  case class WebScrap(strategy: WebScrappingStrategy) {
    def dailyDeal(url:String) = strategy( url )

Note that we have used a case class but we could as well use a method to achieve the same effect:

def dailyDeal( url:String, webScrappingStrategy: WebScrappingStrategy ) = webScrappingStrategy( url )

Then we’ll get busy with web-scrapping publisher websites.

The Manning Daily Deal web-scrapper Strategy:

    def ManningWebScrappingStrategy: WebScrappingStrategy  =
      (url:String) =>
      Jsoup.parse( new WebClient(BrowserVersion.CHROME).getPage( url )
                    .asInstanceOf[HtmlPage].asXml )
        .select("div.dotdbox b").text

Note that the Manning website is using JavaScript to create the Daily Deal section that Jsoup cannot parse therefore we use HtmlUnit.

One step further with the call to the Strategy context case class:

  def ManningDailyDeal = {

    val ManningWebScrappingStrategy: WebScrappingStrategy  =
      (url:String) =>
      Jsoup.parse( new WebClient(BrowserVersion.CHROME).getPage( url )
                    .asInstanceOf[HtmlPage].asXml )
        .select("div.dotdbox b").text

    WebScrap( ManningWebScrappingStrategy ).dailyDeal( "" )

The Strategy Pattern is the last returned line in the above variable:

WebScrap( ManningWebScrappingStrategy ).dailyDeal( "" )

The url is inherent to the Strategy and ultimately to the Publisher therefore the above grouping under the ManningDailyDeal variable.

Similarly here are the other Publisher Strategies:

  def OReillyDailyDeal = {

    val OReillyWebScrappingStrategy: WebScrappingStrategy = Jsoup.connect(_)"a[href$=DEAL] strong").get(0).text

    WebScrap( OReillyWebScrappingStrategy ).dailyDeal( "" )
  def APressDailyDeal = {

    val APressWebScrappingStrategy: WebScrappingStrategy = Jsoup.connect(_)"div.block-dotd").get(0).select("a")

    WebScrap( APressWebScrappingStrategy ).dailyDeal( "" )
  def SpringerDailyDeal = {

    val SpringerWebScrappingStrategy: WebScrappingStrategy = Jsoup.connect(_)"div.block-dotd").get(1).select("a")

    WebScrap( SpringerWebScrappingStrategy ).dailyDeal( "" )

That’s pretty much it for the Strategy Pattern. If we want to take it one step further packing it up in a nice Factory Method OO Pattern:

  trait Publisher
  object Manning extends Publisher
  object APress extends Publisher
  object Springer extends Publisher
  object OReilly extends Publisher

  object DailyDeal {
    def apply(publisher: Publisher) = publisher match {
      case Manning => ManningDailyDeal
      case APress => APressDailyDeal
      case Springer => SpringerDailyDeal
      case OReilly => OReillyDailyDeal

So we can make calls like so:


Full code on this GitHub repository.

Singleton Design Pattern VS Spring Singleton Scope

  • First off, the Singleton design pattern is.. well.. a design pattern whereas Spring’s singleton refers to the singleton scope which by the way is the default bean scope in Spring.
  • The Singleton design pattern is effectively a unique instance of an object per class loader whereas Spring singleton scope ensures the presence of a unique bean per application context.
  • Spring’s singleton scope is uniquely identified by the bean’s id meaning that we can have several beans of the same class type with different ids.
  • Spring’s singleton scoped bean is nothing more than a reference to an object, which, once instantiated, it gets cached by the IoC container and provided upon request. So in short the Spring container that deals with the beans lifecycle is handling internally the bean references and make a reference look like a singleton design pattern-ed object although it’s not.
  • We can have a situation where we inject a prototype-scoped bean into a singleton-scoped bean. That would mean, every time we are requesting the singleton-scoped bean a new object will be injected as a dependency for the prototyped-scoped dependency.

Java Singleton Design Pattern Example

Eagerly created singleton non-multithreaded version:

public class Singleton {

	public static Singleton singleton = new Singleton();
	private Singleton(){}

In the above example it is evident that the public static field is exposing the singleton upon creation. The constructor is of course private and concealed from the outer world.

Eagerly created singleton multithreaded version:

public class Singleton {

	public static volatile Singleton singleton = new Singleton();
	private Singleton(){}

The only addition in the above code is the volatile identifier that is forcing all threads that request read to this variable to cross the memory barrier to the main memory and not rely on JVM registry and cache-local optimisations.

Lazily created singleton multithreaded version:

public class Singleton {

	private static volatile Singleton singleton;
	private Singleton(){}
	public static Singleton getSingleton(){
			singleton = new Singleton();
		return singleton;

In the above example note that the static field has been changed to private scope so only accessible from inside the object. Also the field is set to null by default postponing the instantiation when the singleton is first needed. Moreover, it has been added a factory method lazily instantiates the singleton.