Being able to clarify exactly what a parameter means is a very useful technique to use in a DSL. Not only does it improve the readability of the DSL but it can also remove potential ambiguities. Looking back at our GeeTwitter DSL from the last chapter, we had a sendMessage call, which sends a text message to a Twitter user. Both the message parameter and the user id parameter were defined as strings, which of course could lead to ambiguity in the calling sequence.

def sendMessage(id, message) {
    println "Sending (${message}) to ${id}"
}

// Correct
sendMessage "GroovyDSL", "Hi from GeeTwitter"
// Incorrect
sendMessage"Hi fromGeeTwitter", "GroovyDSL"

The second invocation here would of course cause an exception in the real GeeTwitter as we try to send a message to a user called "Hi from GeeTwitter" instead of to GroovyDSL. A small change removes this ambiguity and improves the readability of the DSL.

def sendMessage(id, message) {
    println "Sending (${message}) to ${id.to}"
}

// Correct
sendMessage to: "GroovyDSL", "Hi fromGeeTwitter"
// Correct – order is no longer important
sendMessage"Hi fromGeeTwitter", to: "GroovyDSL"

It might seem a little redundant or inefficient, from a programming point of view, to package a single value in a map. However, even though we are only going to pass the single value to a parameter along with a message parameter, naming this to parameter adds significantly to the resulting DSL script in terms of legibility.

It would be useful to have a means of constructing objects such that the method of construction was hidden. Enter the builder design pattern. The concept of a design pattern comes originally from the architectural profession in the late 1970s. In building architecture, a design pattern refers to the reuse of design solutions for similar problems. In office complexes, the collocating of stairwells, elevators, and bathrooms around central service columns is a typical design pattern.

Using such a design pattern, architects designing large office buildings can quickly lay out floor after floor of the building by repeating the layouts around the service columns on each floor. This leaves more time and effort to be expended on developing the functional work areas and aesthetics of the building. This not only benefits the architect but also benefits the user of the building.

No matter where we travel, whether it is to Bangkok, San Francisco, Paris, or London, it's usually not too difficult to find a bathroom presuming we can remember how to find our way back to the elevator that we came up in. When we do, we are benefiting from the application of a design pattern.

Design patterns are seldom invented. Instead, they are usually observed in existing buildings and catalogued. Good design evolves over time and is repeated again and again. By exploiting existing design patterns, the architect can rely on the experience of generations of previous building projects and be sure that at least these elements of the building will work as expected.

Design patterns began to be observed and catalogued in software engineering in the late eighties. Ward Cunningham and Kent Beck wrote one of the first conference papers on the subject at OOPSLA 1987. By 1994, the seminal work by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides—Design Patterns: Elements of Reusable Object-Oriented Software—was published, which catalogued over 20 reusable design patterns, including the Model View Controller (MVC) and Factory and Builder patterns.

These authors were not claiming to have invented all of these patterns. For each of the patterns, they listed source systems where the patterns could be observed in use. Some came from ET++, an object-oriented framework developed by Gamma and others at Taligent. Many of the patterns, including MVC and Builder, originated from the Smalltalk language and framework.

We will focus our attention on the builder design pattern. The builder pattern originates from the Parser, ClassBuilder, and ByteCodeStream classes in Smalltalk. Gamma and the others describe its intent in their book as to "separate the construction of a complex object from its representation so that the same construction process can create different representations". The builder pattern has four components:

An important and powerful part of Groovy is its implementation of the Builder pattern. In the UML diagram of the Builder pattern above, we would expect that the Director component might be implemented through a Director class. The Groovy implementation goes beyond this by providing a mini DSL, which appears to embed the building process right into the language.

This style of markup is known as GroovyMarkup, and whose code looks more like a customized markup script than a regular Groovy script. This is due to the clever use of the Groovy's Meta Object Protocol (MOP) and closures.

At first glance, Groovy's builders defy our understanding of how things should work in an object-oriented language. We no longer seem to be creating objects and invoking methods as we would expect. For this section, let's suspend our disbelief and just enjoy the power that Groovy builders provide.

Here we will just try to understand how to use GroovyMarkup to build things. Later on in the chapter, we will cover how the MOP works, and it will become clear what tricks are being employed by the Groovy designers in order to give us a very neat way of constructing complex objects.

The best way to illustrate the GroovyMarkup feature is by way of an example. We'll start with something simple. Suppose that we need to export customer records from our e-commerce package in such a way that they can be used to initialize the customer database of a new CRM system that has been installed by us. The CRM system accepts customer records formatted in XML with customer IDs, names, and addresses. The XML required might look like this:

<customers>
  <customer id='1001'>
    <name firstName='Fred' surname='Flintstone' />
    <address street='1 Rock Road' city='Bedrock' />
  </customer>
  <customer id='1002'>
    <name firstName='Barney' surname='Rubble' />
    <address street='2 Rock Road' city='Bedrock' />
  </customer>
</customers>

Constructing this simple snippet of XML in Java requires numerous method calls to create XML elements and to set attributes of these elements. The nested structure of the document would need to be explicitly constructed by appending some elements as children of other elements. By the time that we are done coding, the procedural nature of the construction process means that the code doing the markup bears no resemblance to the end result XML.

def builder = new groovy.xml.MarkupBuilder()

def customers = builder.customers {
    customer(id:1001) {
        name(firstName:"Fred",surname:"Flintstone")
        address(street:"1 Rock Road",city:"Bedrock") 
    }
    customer(id:1002) {
        name(firstName:"Barney",surname:"Rubble")
        address(street:"2 Rock Road",city:"Bedrock") 
    }    
} 

def builder = new groovy.xml.MarkupBuilder(
                      new FileWriter("customers.xml"))

def customers = builder.customers {
    customer(id:1001) {
        name(firstName:"Fred",surname:"Flintstone")
        address(street:"1 Rock Road",city:"Bedrock") 
    }
    customer(id:1002) {
        name(firstName:"Barney",surname:"Rubble")
        address(street:"2 Rock Road",city:"Bedrock") 
    }    
}

What if we would like to create namespaced XML? In GroovyMarkup, tags conform to the method call syntax. So how can we do that if namespace:tag is not a valid Groovy method name? Fortunately, there is a way around this. In order to insert the colon into a tag name, we simply surround the element name in quotes. Groovy allows us to invoke a method by using a string in place of the method name, so "myMethod"() is treated the same as myMethod().

def xml = new groovy.xml.MarkupBuilder()

def params = [:]

params."xmlns:bk" = "urn:loc.gov:books"
params."xmlns:isbn" = "urn:ISBN:0-393-36341-6"

def bk_tag = "bk:book"
xml."bk:book"(params) {
    "bk:title"("Cheaper by the Dozen")
    "isbn:number"(1568491379)
}

Here we are using the strings' references to set the xmlns namespaces for bk and isbn. Then we use strings to declare the element names in our markup. All of this results in the following output:

<bk:book xmlns:bk='urn:loc.gov:books' xmlns:isbn='urn:ISBN:0-393-36341-6'>
  <bk:title>Cheaper by the Dozen</bk:title>
  <isbn:number>1568491379</isbn:number>
</bk:book>

This technique is not limited to namespaces. We can use it anywhere that we need to output a character in a tag name, which would otherwise not be valid as a Groovy method name (for instance, hyphenated element names). Any Groovy string can be used as an element name, so the following is also valid, where we use ${book_title} to paste the tag name into the markup from a local variable:

def xml = new groovy.xml.MarkupBuilder()

def book = "bk-book"
def book_title = "bk-title"

xml."${book}" {
    "${book_title}"("Cheaper by the Dozen")
    "isbn-number"(1568491379)
}

The MarkupBuilder class will slavishly emit whatever we ask it to. In the previous code snippet, we are creating namespaces by using standard markup with the MarkupBuilder class. A more elegant way of creating namespaced XML is by using the StreamingMarkupBuilder class, which has built-in support for namespaces.

StreamingMarkupBuilder decouples the output of the markup from the creation of the markup closure. We then bind the closure to the StreamingMarkupBuilder at the time at which we want the output to take place.

def xml = new groovy.xml.StreamingMarkupBuilder()

def markup = {
    customers {
        customer(id:1001) {
            name(firstName:"Fred",surname:"Flintstone")
            address(street:"1 Rock Road",city:"Bedrock") 
        }
        customer(id:1002) {
            name(firstName:"Barney",surname:"Rubble")
            address(street:"2 Rock Road",city:"Bedrock") 
        }    
    }     
}

println xml.bind( markup )

Within the closure, we can reference a variable, mkp, which allows us to give instructions to the builder in order to control XML generation. Two handy methods we can invoke are xmlDeclaration(), which causes the XML declaration header to be output, and declareNamespace(), which sets up a namespace.

def xml = new groovy.xml.StreamingMarkupBuilder().bind
{
    mkp.xmlDeclaration()
    mkp.declareNamespace('bk':'urn:loc.gov:books')
    mkp.declareNamespace('isbn':'urn:ISBN:0-393-36341-6')
    
    println mkp.class

    bk.book {
        bk.title("Cheaper by the Dozen")
        isbn.number(1568491379)
    }
}

println xml

Once we have made the builder aware of our namespaces, we can utilize them in the markup code by using suffix notation. So namespace.tag will be output in the XML as namespace:tag, as follows:

<?xml version="1.0"?>
<bk:book xmlns:bk='urn:loc.gov:books' xmlns:isbn='urn:ISBN:0-393-36341-6'>
   <bk:title>Cheaper by the Dozen</bk:title>
   <isbn:number>1568491379</isbn:number>
</bk:book>

def customers = builder.customers {
...

customer(id:1001) {
...

title("Mr")
name(firstName:"Fred",surname:"Flintstone")
address(street:"1 Rock Road",city:"Bedrock")

We can try to understand GroovyMarkup in the context of the builder pattern described earlier.

With MarkupBuilder, it's also just as easy to build HTML pages. Here we generate a simple HTML page:

def html = new groovy.xml.MarkupBuilder()

html.html {
    head {
        title "Groovy Builders"
    }
    body {
        h1 "Groovy Builders are cool!"
    }
}

In the next example, we build a more complex HTML page containing nested tables. MarkupBuilder will close all tags correctly so that they are well formed. A classic mistake when working with nested tag formats is to misplace or unbalance the closing of tags. The HTML <table> tag and its nested <tr> and <td> tags are highly prone to error when hand-coded. Assume that we want to generate HTML to display the names of the various Groovy Builder and ConcreteBuilder classes in a nested table.

The HTML to produce this table would be something like the following:

<html>
<body>
 <table border="1">
  <tr>
    <th>Builder class</th>
    <th>Concrete Class</th>
  </tr>
  <tr>
    <td>groovy.util.BuilderSupport</td>
    <td>
      <table>
        <tr><td>groovy.util.AntBuilder</td></tr>
        <tr><td>groovy.xml.MarkupBuilder</td></tr>
       </table>
      </td>
  </tr>
  <tr>
    <td>groovy.util.FactoryBuilderSupport</td>
    <td>
      <table>
        <tr><td>groovy.util.NodeBuilder</td></tr>
        <tr><td>groovy.swing.SwingBuilder</td></tr>
       </table>
      </td>
  </tr>
 </table>
</body>
</html> 

Although the HTML above looks correct, one of the TABLE tags is incorrectly terminated as </td>. Displaying the above code in a browser would show an extra layer of nesting in the TABLE that was not intended. The same HTML can be generated using MarkupBuilder as shown in the following listing:

def html = new groovy.xml.MarkupBuilder()
html.html {
    head {
        title "Groovy Builders"
    }
    body {
        table(border:1) {
            tr {
                th "Builder class"
                th "Concrete class"
            }
            tr {
                td "groovy.util.BuilderSupport"
                td {
                    table { 
                        tr {
                            td "groovy.util.AntBuilder"
                        }
                        tr {
                            td "groovy.xml.MarkupBuilder"
                        }
                     }
                }
            }
            tr {
                td "groovy.util.FactoryBuilderSupport"
                td {
                    table { 
                        tr {
                            td "groovy.util.NodeBuilder"
                        }
                        tr {
                            td "groovy.swing.SwingBuilder"
                        }
                     }
                }
            }
        }
    }
}

In the Groovy version, all of the tags that are produced are guaranteed to be correct with respect to nesting and balancing. The Groovy version also looks much less cluttered and readable. In fact, it is impossible for us to make the same type of errors with the Groovy version, as the compiler will insist that all parentheses are properly balanced.

So far we have just used Groovy builders as straightforward markup scripts. In spite of the unusual syntax, GroovyMarkup scripts are still just plain Groovy scripts; so there is nothing stopping us from mixing the construction process with regular program logic if we please. Here we iterate over a list of customer data while generating XML from the customer records that we find.

def builder = new groovy.xml.MarkupBuilder()

class Customer {
    int id
    String firstName
    String surname
    String street
    String city
}
def fred = new Customer(id:1001,firstName:"Fred", surname:"Flintstone",
street:"1 Rock Road",city:"Bedrock")
def barney =  new Customer(id:1002,firstName:"Barney", surname:"Rubble",
street:"2 Rock Road",city:"Bedrock")
def customerList = [ fred, barney]
    
def customers = builder.customers {
    for (cust in customerList) {
        customer(id:cust.id) {
            name(firstName:cust.firstName,surname:cust.surname)
            address(street:cust.street, city:cust.city) 
        }
    }
}

Out of the box, the Groovy libraries include a suite of builders for most of the common construction tasks that we might encounter. Here is a list of some of them:

def builder = new groovy.util.NodeBuilder()

class Customer {
    int id
    String firstName
    String surname
    String street
    String city
}
def fred = new Customer(id:1001,firstName:"Fred", surname:"Flintstone",
    street:"1 Rock Road",city:"Bedrock")
def barney =  new Customer(id:1002,firstName:"Barney", surname:"Rubble",
    street:"2 Rock Road",city:"Bedrock")
def wilma = new Customer(id:1003,firstName:"Wilma", surname:"Flintstone",
    street:"1 Rock Road",city:"Bedrock")
def betty =  new Customer(id:1004,firstName:"Betty", surname:"Rubble",
    street:"2 Rock Road",city:"Bedrock")
def customerList = [ fred, barney,wilma,betty]
    
def customers = builder.customers {
    for (cust in customerList) {
        customer(id:cust.id) {
            name(firstName:cust.firstName,surname:cust.surname)
            address(street:cust.street, city:cust.city) 
        }
    }
}

assert customers.customer[0].'@id' == 1001
assert customers.customer[1].'@id' == 1002
assert customers.customer[0].address[0].'@street' == 
                       customers.customer[2].address[0].'@street'
assert customers.grep{ 
     it.name.any{it.'@surname' == "Rubble"}
}.size == 2
assert  customers.grep{ 
     it.name.any{it.'@surname' == "Rubble"}
}.address.every{ it.'@street'[0] == "2 Rock Road"}

assert customers.customer[0].'@id' == 1001
assert customers.customer[1].'@id' == 1002

customers.customer.each {
    println it.name[0].'@firstName'
    }

assert customers.customer[0].address[0].'@street'
 == customers.customer[1].address[0].'@street'

def rubbles = customers.grep{ it.name.any{it.'@surname' == "Rubble"}}

assert rubbles.address.every{ it.'@street'[0] == "2 Rock Road"}

If you like the look of SwingBuilder, then take a look at the Griffon project. Griffon is a Grails-like application framework for desktop application development. Griffon provides an MVC paradigm where the view portion of the application can be coded in the Builder of your choice.

Griffon adds the framework and runtime support around the Builder code so that only the markup needs to be written to create a View. Here is the View code for a simple Griffon application:

application(title:'DemoConsole', pack:true, locationByPlatform:true) {
  panel(border:emptyBorder(6)) {
    borderLayout()

    scrollPane(constraints:CENTER) {
      textArea(text:bind(target:model, 
         targetProperty:'scriptSource'),
         enabled: bind {model.enabled},
         columns:40, rows:10)
    }

    hbox(constraints:SOUTH) {
      button("Execute",
         actionPerformed:controller.&executeScript,
         enabled: bind {model.enabled})
         hstrut(5)
         label("Result:")
         hstrut(5)
         label(text:bind {model.scriptResult})
    }
  }
}

The set-up code for the Builder objects is not necessary as Griffon takes care of this. Used in this context, Builder markup code is now more like a declarative DSL for the user interface. Later on in the book, we will take a look at how another Groovy project Gant uses AntBuilder in a similar fashion, to make a declarative Groovy DSL replacement for Ant scripts.

To use Java reflection, we first need to access the Class object for any Java object we in which are interested through its getClass() method. Using the returned Class object, we can query everything from the list of methods or fields of the class to the modifiers that the class was declared with. Below, we see some of the ways that we can access a Class object in Java and the methods we can use to inspect the class at runtime.

import java.lang.reflect.Field;
import java.lang.reflect.Method;

public class Reflection {
   public static void main(String[] args) {
      String s = new String();
      Class sClazz = s.getClass();
      Package _package = sClazz.getPackage();
      System.out.println("Package for String class: ");
      System.out.println("    " +  _package.getName());
      Class oClazz = Object.class;
      System.out.println("All methods of Object class:");
      Method[] methods = oClazz.getMethods();
      for(int i = 0;i < methods.length;i++)
         System.out.println("    " + methods[i].getName());
      try {
         Class iClazz = Class.forName("java.lang.Integer");
         Field[] fields = iClazz.getDeclaredFields();
         System.out.println("All fields of Integer class:");
         for(int i = 0; i < fields.length;i++)
            System.out.println("    " + fields[i].getName());
      } catch (ClassNotFoundException e) {
         e.printStackTrace();
      }
   }
}

We can access the Class object from an instance by calling its Object.getClass() method. If we don't have an instance of the class to hand, we can get the Class object by using .class after the class name, for example, String.class. Alternatively, we can call the static Class.forName, passing to it a fully-qualified class name.

Class has numerous methods, such as getPackage(), getMethods(), and getDeclaredFields() that allow us to interrogate the Class object for details about the Java class under inspection. The preceding example will output various details about String, Integer, and Double.

Groovy Reflection shortcuts

Groovy, as we would expect by now, provides shortcuts that let us reflect classes easily. In Groovy, we can shortcut the getClass() method as a property access .class, so we can access the class object in the same way whether we are using the class name or an instance. We can treat the .class as a String, and print it directly without calling Class.getName(), as follows:

The variable greeting is declared with a dynamic type, but has the type java.lang.String after the "Hello" String is assigned to it. Classes are first class objects in Groovy so we can assign String to a variable. When we do this, the object that is assigned is of type java.lang.Class. However, it describes the String class itself, so printing will report java.lang.String.

Groovy also provides shortcuts for accessing packages, methods, fields, and just about all other reflection details that we need from a class. We can access these straight off the class identifier, as follows:

println "Package for String class"
println "    " + String.package
println "All methods of Object class:"
Object.methods.each { println "    " + it }
println "All fields of Integer class:"
Integer.fields.each { println "    " + it }

Incredibly, these six lines of code do all of the same work as the 30 lines in our Java example. If we look at the preceding code, it contains nothing that is more complicated than it needs to be. Referencing String.package to get the Java package of a class is as succinct as you can make it. As usual, String.methods and String.fields return Groovy collections, so we can apply a closure to each element with the each method. What's more, the Groovy version outputs a lot more useful detail about the package, methods, and fields.

When using an instance of an object, we can use the same shortcuts through the class field of the instance.

def greeting = "Hello"
assert greeting.class.package == String.package 

An Expando is a dynamic representation of a typical Groovy bean. Expandos support typical get and set style bean access but in addition to this they will accept gets and sets to arbitrary properties. If we try to access, a non-existing property, the Expando does not mind and instead of causing an exception it will return null. If we set a non-existent property, the Expando will add that property and set the value. In order to create an Expando, we instantiate an object of class groovy.util.Expando.

def customer = new Expando()

assert customer.properties == [:]

assert customer.id == null

assert customer.properties == [:]

customer.id = 1001
customer.firstName = "Fred"
customer.surname = "Flintstone"
customer.street = "1 Rock Road"

assert customer.id == 1001

assert customer.properties == [
    id:1001, firstName:'Fred', 
    surname:'Flintstone', street:'1 Rock Road']
customer.properties.each { println it }

The id field of customer is accessible on the Expando shown in the preceding example even when it does not exist as a property of the bean. Once a property has been set, it can be accessed by using the normal field getter: for example, customer.id. Expandos are a useful extension to normal beans where we need to be able to dump arbitrary properties into a bag and we don't want to write a custom class to do so.

A neat trick with Expandos is what happens when we store a closure in a property. As we would expect, an Expando closure property is accessible in the same way as a normal property. However, because it is a closure we can apply function call syntax to it to invoke the closure. This has the effect of seeming to add a new method on the fly to the Expando.

customer.prettyPrint = {
    println "Customer has following properties"  
    customer.properties.each {
        if (it.key != 'prettyPrint')
            println "    " + it.key + ": " + it.value 
    } 
}

customer.prettyPrint()

Here we appear to be able to add a prettyPrint() method to the customer object, which outputs to the console:

Customer has following properties
    surname: Flintstone
    street: 1 Rock Road
    firstName: Fred
    id: 1001 

Adding a closure to an Expando to give a new method is a useful feature, but what if we need to add methods to an existing class on the fly? Groovy provides another useful feature—Categories—for this purpose. A Category can be added to any class at runtime, by using the use keyword.

We can create Category classes that add methods to an existing class. To create a Category for class, we define a class containing static methods that take an instance of the class that we want to extend as their first parameter. By convention, we name this parameter as self. When the method is invoked, self is set to the object instance that we are extending. The Category can then be applied to any closure by using the use keyword.

class Customer {
    int id
    String firstName
    String surname
    String street
    String city
}

def fred = new Customer(id:1001,firstName:"Fred", surname:"Flintstone",
street:"1 Rock Road",city:"Bedrock")
def barney =  new Customer(id:1002,firstName:"Barney", surname:"Rubble",
street:"2 Rock Road",city:"Bedrock")

def customerList = [ fred, barney]

class CustomerPrinter {
    static void prettyPrint(Customer self) {
        println "Customer has following properties"  
        self.properties.each {
            if (it.key != 'prettyPrint')
                println "    " + it.key + ": " + it.value 
        } 
    }
}

use (CustomerPrinter) {
    for (customer in customerList)
        customer.prettyPrint()
}

Java libraries are full of classes that have been declared final. The library designers in their wisdom have decided that the methods they have added are all that we will ever need. Unfortunately, that is almost never the case in practice. Take the Java String class, for example. There are plenty of useful string manipulation features that we might like to have in the String class. Java has added methods progressively to this class over time: for instance, match and split in Java 1.4, with replace and format being added in Java 1.5.

If we needed these style methods before Sun got around to adding them, we could not do it ourselves because of the final modifier. So the only option has been to use classes from add-on libraries such as Commons StringUtils. The Apache Commons Lang component class contains a slew of useful classes that augment the basic capabilities of Java classes, including BooleanUtils, StringUtils, DateUtils, and so on. All of the util class methods are implemented as static, taking String as the first parameter. This is the typical pattern used in Java when we need to mix in extra functionality to an existing class.

import org.apache.commons.lang.StringUtils;

public class StringSplitter {

   public static void main(String[] args) {
      String [] splits = StringUtils.split(args[0], args[1]);

      for (int i = 0; i < splits.length; i++) {
         System.out.println("token : " + splits[i]);
      }
   }
}

Conveniently, this pattern is the same as the one used Groovy categories, which means that the Apache Commons Lang Util classes can all be dropped straight into a use block. So all of these useful utility classes are ready to be used in your Groovy code as Categories.

import org.apache.commons.lang.StringUtils

use (StringUtils) {
    "org.apache.commons.lang".split(".").each { println it }
}

In addition to the regular Java Class object that we saw earlier when looking at reflection, each Groovy object also has an associated MetaClass Object. All Groovy classes secretly implement the groovy.lang.GroovyObject interface, which exposes a getMetaClass() method for each object.

public interface GroovyObject {
    /**
     * Invokes the given method.
     */
    Object invokeMethod(String name, Object args);

    /**
     * Retrieves a property value.
     */
    Object getProperty(String propertyName);

    /**
     * Sets the given property to the new value.
     */
    void setProperty(String propertyName, Object newValue);

    /**
     * Returns the metaclass for a given class.
     */
    MetaClass getMetaClass();

    /**
     * Allows the MetaClass to be replaced with a 
     * derived implementation.
     */
    void setMetaClass(MetaClass metaClass);
}

Pure Java classes used in Groovy do not implement this interface, but they have a MetaClass assigned anyway. This MetaClass is stored in the MetaClass registry. Earlier versions of Groovy required a look-up in the registry to access the MetaClass. Since Groovy 1.5, the MetaClass of any class can be found by accessing its .metaClass property.

class Customer {
    int id
    String firstName
    String surname
    String street
    String city
}

// Access Groovy meta class
def groovyMeta = Customer.metaClass

// Access Java meta class from 1.5
def javaMeta = String.metaClass

// Access Groovy meta class prior to 1.5
def javaMetaOld = GroovySystem.metaClassRegistry.getMetaClass(String)

Metaclasses are the secret ingredients that make the Groovy language dynamic. The MetaClass maintains all of the metadata about a Groovy class. This includes all of its available methods, fields, and properties. Unlike the Java Class object, the Groovy MetaClass allows fields and methods to be added on the fly. So while the Java class can be considered as describing the compile time behavior of the class, the MetaClass describes its runtime behavior. We cannot change the Class behavior of an object but we can change its MetaClass behavior by adding properties or methods on the fly.

The Groovy runtime maintains a single MetaClass per Groovy class, and these operate in close quarter with the GroovyObject interface. GroovyObject implements a number of methods, which in their default implementations are just facades to the equivalent MetaClass methods. The most important of these to understand is the invokeMethod().

class Customer {
    int id
    String firstName
    String surname
    String street
    String city
    
    Object invokeMethod(String name, Object args) {
        if (name == "prettyPrint") {        
            println "Customer has following properties"  
            this.properties.each {
                println "    " + it.key + ": " + it.value 
            }
        }
    }
}

def fred = new Customer(id:1001,firstName:"Fred", 
    surname:"Flintstone", street:"1 Rock Road",city:"Bedrock")
def barney =  new Customer(id:1002,firstName:"Barney", 
    surname:"Rubble", street:"2 Rock Road",city:"Bedrock")

def customerList = [ fred, barney]

customerList.each { it.prettyPrint() }

Like Java, Groovy has a this keyword that refers to the "current" or enclosing Java object. In Java, we don't have any other context that we can execute code in except a class method. In an instance method, this will always refer to the instance itself. In a static method, this has no meaning as the compiler won't allow us to reference this in a static context.

In addition to the instance methods, Groovy has three additional execution contexts to be aware of:

In addition to the this keyword, Groovy has two other keywords that are referred only in the context of a closure—owner and delegate.

The following example illustrates this, owner, and delegate working under various different contexts. This example is necessarily complex, so take the time to read and understand it.

class Clazz {
 void method() {
        println "Class method this is : " + this.class
    }
 void methodClosure() {
       def methodClosure = {
            println "Method Closure this is : " + this.class
            assert owner == this
            assert delegate == this           
       }
       methodClosure()
    }
}

def clazz = new Clazz()

clazz.method()

def closure = { self ->
    println "Closure this is : " + this.class
    assert this == owner
    assert delegate == clazz
    def closureClosure = {
        println "Closure Closure this is : " + this.class
        assert owner == self


        assert delegate == self
    }
    assert closureClosure.delegate == self
    
    closureClosure()
    
}

closure.delegate = clazz
closure(closure)
clazz.methodClosure()

println this.class

Running the preceding code will output the following text:

Class method this is : class Clazz
Closure this is : class ConsoleScript1
Closure Closure this is : class ConsoleScript1
Method Closure this is : class Clazz
Script this is : class ConsoleScript1

So the rules for resolving this, owner, and delegate in the various contexts are:

The technique that we use to add a method can also be used to replace an existing method. When doing so, we can subvert the existing logic of a class. Wouldn't it be nice if we could change all bank managers' minds as easily as this?

class BankManager {
    def loan_approval_status = false
    
    boolean approveLoan() {
        return loan_approval_status
    }
}

def myBankManager = new BankManager()

assert myBankManager.approveLoan() == false

BankManager.metaClass.approveLoan = { true }

myBankManager = new BankManager()
assert myBankManager.approveLoan() == true

Any method can be overridden or added. This includes any of the operator methods, such a plus(), minus(), multiply(), divide(), and so on. If need be, we can add operator semantics to any class, even if we have not written it ourselves.

To add or override a static method of a class, we just insert the static keyword before the method name. In this example, we take the abstract Calendar class and supply a static getInstance method that instantiates a GregorianCalendar object. We then add a static now method that makes use of the new instance.

Calendar.metaClass.static.getInstance = { new GregorianCalendar() }

println Calendar.getInstance().getTime()

Calendar.metaClass.static.now = { Calendar.getInstance().getTime() }

println Calendar.now()

We can use GStrings to name methods as we add or override them in a class. This means that we can dynamically generate method names on the fly. In the following example, we iterate all of the properties in the Customer class. We can exclude the class and metaClass properties with the find operator it =~ /lass/ so that we just add methods for the properties that we want.

class Customer {
    def firstName
    def lastName
    def address1
    def address2
}

def c = new Customer()
// Find all properties except class and metaClass and add 
// a new print(field) method
c.properties.keySet().findAll { !(it =~ /lass/)} .each {
 Customer.metaClass."print_${it}" = { -> println delegate."${it}" }
}
def cust = new Customer(firstName:"Fred", 
                 lastName:"Flintstone", 
                 address1:"Rock Road", 
                 address2:"Bedrock")

cust.print_firstName()
cust.print_lastName()

Whenever we add a method to the ExpandoMetaClass that has the same signature as an existing method, the original method is overridden. In the following snippet, we can see that it is the last String blanked method that is in place after we override on subsequent occasions.

String.metaClass.blanked = { delegate.replaceAll(/./) {'%'} }
String.metaClass.blanked = { delegate.replaceAll(/./) {'@'} }
String.metaClass.blanked = { delegate.replaceAll(/./) {'*'} }

assert "A String".blanked() == "********" 

To add overloaded versions of methods, we can continue to add new methods. As long as the signatures are different from the last each method, it will be added as an overloaded method.

String.metaClass.static.valueAndType = { double d -> 
    "${d.class.name}:${valueOf(d)}"
}
String.metaClass.static.valueAndType = { float f ->
    "${f.class.name}:${valueOf(f)}"
}
String.metaClass.static.valueAndType = { int i -> 
    "${i.class.name}:${valueOf(i)}"
}
String.metaClass.static.valueAndType = { long l ->
    "${l.class.name}:${valueOf(l)}"
}

assert String.valueAndType(1.0) == "java.lang.Double:1.0"
assert String.valueAndType(3.333f) == "java.lang.Float:3.333"
assert String.valueAndType(101) == "java.lang.Integer:101"
assert String.valueAndType(1000000L) == "java.lang.Long:1000000"

When we are overloading subsequent methods with different signatures, we can make use of the append operator <<.

String.metaClass {
 static.valueAndType << { double d -> 
    "${d.class.name}:${valueOf(d)}"
 }
 static.valueAndType << { float f ->
    "${f.class.name}:${valueOf(f)}"
 }
 static.valueAndType << { int i ->
    "${i.class.name}:${valueOf(i)}"
 }
 static.valueAndType << { long l ->
    "${l.class.name}:${valueOf(l)}"
 }
}

assert String.valueAndType(1.0) == "java.lang.Double:1.0"
assert String.valueAndType(3.333f) == "java.lang.Float:3.333"
assert String.valueAndType(101) == "java.lang.Integer:101"
assert String.valueAndType(1000000L) == "java.lang.Long:1000000"

Constructors can be added to a class by using the constructor property of the metaclass. Just be wary when doing this so as not to call the default constructor. The mechanism used by the metaclass to call the constructor will cause a stack overflow, if you do.

class Customer {
    def firstName
    def lastName
    def address1
    def address2
}

Customer.metaClass.constructor  = { 
    String first, String last -> new Customer(
firstName:first,
lastName:last) 
}

def c = new Customer("Fred", "Flintstone" )