Groovy lends itself to be extremely useful as a builder for all sorts of data structures. This article intends to investigate why that is. What exactly are builders? And why is groovy so good at it.

To answer these questions, 2 important concepts need to be addressed first

  1. DSL - Domain Specific Languages
  2. The Builder Pattern

Domain Specific Languages

He that is good with a hammer tends to think everything is a nail — Abraham Maslow

Advocates of ruby, and more recently groovy have traditionally embraced the “best tool for the job” attitude. The Pragmatic Programmer (a must have in any developers bookshelf ) suggests learning a new language every year. For some this might be taking it a step too far, but it definitely fits the former argument.

Computer science knows all too many one trick ponies who get stuck inside that one language of their choosing, and spend the majority of their free time insecurely and childishly flaming the new programming language on the block. The evident truth is that one shoe never first all, and a little flexibility in mindset goes a long way towards solving a problem. Which brings us to the concept of a DSL

The basic idea of a domain specific language (DSL) is a computer language that’s targeted to a particular kind of problem, rather than a general purpose language that’s aimed at any kind of software problem. Domain specific languages have been talked about, and used for almost as long as computing has been done. – Martin Fowler

XML is the current reigning king of this field. Unfortunately one may add . From a java background you’ll be familiar with XML as a DSL for:

  • Spring Configuration
  • Ant build files
  • log4j
  • hibernate mappings (pre annotations)
  • container configs (Tomcat / JBOSS / …)
  • web.xml

With all the advantages that XML files do carry. Such as allowing a strict definition through XSL/DTD as well as being able to define any datatype you wish, there is one major pitfall. XML is not a programming language and there is no concept of even a simple loop, which is particularly limiting in something like an ant build file.

Groovy suits itself perfectly as a DSL, because of its loose syntax allowing all sorts of creative possibilities. Closures, easy map definition and the metaclass being key.

The grails framework is a perfect example. GORM - the DSL for hibernate code allows you to define domain classes as follows.

  class Author {
	String email
	String username
	String password

	static hasMany = [books:Book]

	static constraints = {
           email(email:true, blank:false, unique:true)
           username(size:4..15, blank:false,unique:true)
           password(size:4..25, blank:false)
       }
   }

The code is readable, and easily understandable, by people unfamiliar with hibernate or groovy. GORM has in essence defined a DSL (leveraging groovy) to define the model, and the relationships which need to be mapped to the database.

Grails Controllers also utilize groovy in a similar way to provide a DSL for spring web-mvc.

The Builder Pattern

The Builder Pattern aims to seperate the creation of complex objects, the product, from its representation.

In a simple example:

If we define the creation steps of compiling our project, generating a war, deploying the war to the server, reloading tomcat in our own custom builder syntax “GroovyBuilder”. We could then still freely choose the actual representation. Do we generate an ANT build.xml from it. Or a linux shell script, even a dos batch file? “GroovyBuilder” is a generic syntax for building our choice of implementation of production steps.

Looking back at the example above from the GORM domain class Author, we could now also say that GORM is a builder for hibernate mappings. GORM seperates the creation of the model and its relationships from the represenation (the hibernate mapping).

GANT - Groovy Ant

GANT is a good example to put all of this together.

Below is a simple ant config:

<target name="compile">
   <mkdir dir="target/classes" />
   <javac srcdir="src" destdir="target/classes" />
</target>

The GANT counterpart

target(compile:"compiles source code"){
   Ant.mkdir(dir:"target/classes")
   Ant.javac(srcdir:"src", destdir:"target/classes")
}

At first site, this might not seem like all too much of an improvement. But the GANT code is pure groovy. Meaning all the conditional logic, and variable declaration is available to the developer. For larger build files this is a godsend.

There are many other, builders out there, which i’d like to expand upon, soon.

Critics and comments welcome ;)