concept closure in category groovy

This is an excerpt from Manning's book Groovy in Action, Second Edition. Login to get full access to this book.

Unfortunately, many of the features can’t be understood in just a few words. Closures, for example, are an invaluable language concept in Groovy, but the word on its own doesn’t tell you anything. We won’t go into all the details now, but here are a few examples to whet your appetite.

Figure 2.5. A simple example of a closure that prints the numbers 1, 2, and 3

Closures are important. Very important. They’re arguably one of the most useful features of Groovy. But at the same time they can be a strange concept until you fully understand them. To get the best out of Groovy, or to understand anyone else’s Groovy code, you’re going to have to be comfortable with closures. Not just “met them once at a wedding” comfortable, but “invite them over for a barbecue on the weekend” comfortable.

Now, we don’t want to scare you away. Closures aren’t hard—they’re just different than anything you might be used to. In a way, this is strange, because one of the chief tenets of object orientation is that objects have behavior as well as data. Closures are objects of which the main purpose in life is their behavior—that’s almost all there is to them.

In previous chapters, you’ve seen a few uses of closures, so you might already have a good idea of what they’re about. Please forgive us if we seem to be going over the same ground again—it’s so important, we’d rather repeat ourselves than leave you without a good grasp of the basic principles.

In this chapter, we’ll introduce the fundamental concept of closures (again), explain their benefits, and then show you how they can be declared and called. After this basic treatment, we’ll look in a bit more depth at other methods available on closures and the scope of a closure—that is, the data and members that can be accessed within it—as well as consider what it means to return from a closure. We end the chapter with a discussion of how closures can be used to implement many common design patterns and how they alleviate the need for some others by solving the problem in a different manner.

So, without further ado, let’s take a look at what closures really are in the first place.

A closure shared variable [var] has been assigned with various types and the
method [toUpperCase()] does not exist in the lowest upper bound of those
types: [java.io.Serializable <? extends java.lang.Object>]. In general, this
is a bad practice (variable reuse) because the compiler cannot determine
safely what is the type of the variable at the moment of the call in a
multithreaded context.

This is an excerpt from Manning's book Making Java Groovy: Foreword by Guillaume Laforge. Login to get full access to this book.

The closure is intended to be the implementation of the compare(String,String) method analogous to that shown in the previous Java listing. Here I show the two dummy arguments, s1 and s2, to the left of the arrow, and then use them on the right side. I provide the closure as the implementation of the Comparator interface. If the interface had several methods and I wanted to supply different implementations for each method, I would provide a map with the names of the methods as the keys and the corresponding closures as the values.

A closure is a block of code, delimited by curly braces, which can be treated as an object. The arrow notation is used to specify dummy arguments. In the closure applied to the map in the current example, the two dummy arguments are k and v, which represent the key and value of each entry. The expression on the right side of the arrow says to substitute each key and value into a GString separated by an equals sign. This collect method takes each entry in the map and converts it into a string with the key assigned to the value, and produces a list of results.