# Chain of Responsibility Pattern

version 2.4.12

In the Chain of Responsibility Pattern, objects using and implementing an interface (one or more methods) are intentionally loosely coupled. A set of objects that implement the interface are organised in a list (or in rare cases a tree). Objects using the interface make requests from the first implementor object. It will decide whether to perform any action itself and whether to pass the request further down the line in the list (or tree). Sometimes a default implementation for some request is also coded into the pattern if none of the implementors respond to the request.

## 1. Example

In this example, the script sends requests to the `lister` object. The `lister` points to a `UnixLister` object. If it can’t handle the request, it sends the request to the `WindowsLister`. If it can’t handle the request, it sends the request to the `DefaultLister`.

    class UnixLister {
        private nextInLine
        UnixLister(next) { nextInLine = next }
        def listFiles(dir) {
            if (System.getProperty('os.name') == 'Linux') {
                println "ls $dir".execute().text
            } else {
                nextInLine.listFiles(dir)
            }
        }
    }

    class WindowsLister {
        private nextInLine
        WindowsLister(next) { nextInLine = next }
        def listFiles(dir) {
            if (System.getProperty('os.name') == 'Windows XP') {
                println "cmd.exe /c dir $dir".execute().text
            } else {
                nextInLine.listFiles(dir)
            }
        }
    }

    class DefaultLister {
        def listFiles(dir) {
            new File(dir).eachFile { f -> println f }
        }
    }

    def lister = new UnixLister(new WindowsLister(new DefaultLister()))

    lister.listFiles('Downloads')

The output will be a list of files (with slightly different format depending on the operating system).

Here is a UML representation:

Variations to this pattern:

- we could have an explicit interface, e.g. `Lister`, to statically type the implementations but because of duck-typing this is optional

- we could use a chain tree instead of a list, e.g. `if (animal.hasBackbone())` delegate to `VertebrateHandler` else delegate to `InvertebrateHandler`

- we could always pass down the chain even if we processed a request

- we could decide at some point to not respond and not pass down the chain

- we could use Groovy’s meta-programming capabilities to pass unknown methods down the chain