Value Oriented

Clojure promotes a style of programming commonly called “value-oriented programming.” Clojure's creator, Rich Hickey, isn't the first person to use that phrase to describe functional programming, but he does an excellent job explaining it in a talk titled The Value of Values that he gave at Jax Conf in 2012 (https://www.youtube.com/watch?v=-6BsiVyC1kM).

By promoting this style of value-oriented programming, we are focused more on the values than mutable objects, which are merely abstractions of places in memory and their current state. Mutation belongs in comic books, and has no place in programming. This is extremely powerful, because it allows you to not have to concern yourself with worrying about who is accessing your data and when. Since you are not worried about what code is accessing your data, concurrency now becomes much more trivial than it ever was in any of the imperative languages.

One common practice when programming in an imperative language is to defensively make a copy of any object passed into a method to ensure that the data does not get altered while trying to use it. Another side effect of focusing on values and immutability is that this practice is no longer necessary. Imagine the amount of code you will no longer have to maintain because you'll be using Clojure.

In object-oriented programming, we are largely concerned with information hiding or restricting access to an object's data through encapsulation. Clojure removes the need for encapsulation because of its focus on dealing with values instead of mutable objects. The data becomes semantically transparent, removing the need for strict control over data. This level of transparency allows you to reason about the code, because you can now simplify complex functions using the substitution model for procedure application as shown in the following canonical example. Here we simplify a function called sum-of-squares through substituting the values:

(defn square [a] (* a a))
(defn sum-of-squares [a b] (+ (square a) (square b))
; evaluate the expression (sum-of-squares 4 5)
(sum-of-squares 4 5)
(+ (square 4) (square 5))
(+ (* 4 4) (* 5 5))
(+ 16 25)
41

By favoring functions that are referentially transparent, you can take advantage of a feature called memorization. You can tell Clojure to cache the value of some potentially expensive computation, resulting in faster execution. To illustrate this, we'll use the Fibonacci sequence, adapted for Clojure, as an example taken from the classic MIT text Structure and Interpretation of Computer Programs (SICP).

(defn fib [n]
  (cond
    (= n 0) 0
    (= n 1) 1
    :else (+ (fib (- n 1))
             (fib (- n 2)))))

If you look at the tree of execution and evaluate the function for the value of 5, you can see that in order to calculate the fifth Fibonacci number, you need to call (fib 4) and (fib 3). Then, to calculate (fib 4), you need to call (fib 3) and (fib 2). That's quite a bit of recalculating values that you already know the answer to (see Figure 1.1).

Calculating for (fib 5) executes quickly, but when you try to calculate for (fib 42) you can see that it takes considerably longer.

(time (fib 42))
"Elapsed time: 11184.49583 msecs"
267914296

You can rewrite a function to leverage memorization to see a significant improvement in the execution time. The updated code is shown here:

(def memoized-fib
  (memoize (fn [n]
             (cond
               (= n 0) 0
               (= n 1) 1
               :else (+ (fib (- n 1))
                        (fib (- n 2)))))))

When you first run this function, you'll see how the execution doesn't happen any faster; however, each subsequent execution instantaneously happens.

user> (time (memoized-fib 42))
"Elapsed time: 10586.656667 msecs"
267914296
user> (time (memoized-fib 42))
"Elapsed time: 0.10272 msecs"
267914296
user> (time (memoized-fib 42))
"Elapsed time: 0.066446 msecs"
267914296

This is a risky enhancement if you do this with a function that relies on a mutable shared state. However, since our functions are focused on values, and are referentially transparent, you can leverage some cool features provided by the Clojure language.

Thinking Recursively

Recursion is not something that is taught much in most imperative languages. Contrast this with most functional languages, and how they embrace recursion, and you will think more recursively. If you are unfamiliar with recursion, or struggle to understand how to think recursively, you should read The Little Schemer, by Daniel P. Friedman and Matthias Felleisen. It walks you through how to write recursive functions using a Socratic style of teaching, where the two authors are engaged in a conversation and you get to listen in and learn.

Let's take a look at a trivial example of calculating a factorial. A typical example in Java might look like the code shown below. You start by creating a local variable to store the ultimate result. Then, loop over every number, one-by-one, until you reach the target number, multiplying the last result by the counter variable defined by the for loop, and mutating the local variable.

public long factorial(int n) {
  long product = 1;
  for ( int i = 1; i <= n; i++ ) {
    product *= i;
  }
  return product;
}

Because of Clojure's focus on values and immutable structures, it relies on recursion for looping and iteration. A naïve recursive definition of a factorial in Clojure may look like the following:

(defn factorial [n]
     (if (= n 1)
          1
          (* n (factorial (- n 1)))))

If you trace the execution of the factorial program with an input of 6, as shown next, you see that the JVM needs to maintain each successive operation on the stack as n increases, until the factorial reaches a point where it returns a value instead of recurring. If you're not careful, you'll likely end up with a stack overflow. This style of recursion is often called linear recursion.

(factorial 6)
(* 6 (factorial 5))
(* 6 (* 5 (factorial 4)))
(* 6 (* 5 (* 4 (factorial 3))))
(* 6 (* 5 (* 4 (* 3 (factorial 2)))))
(* 6 (* 5 (* 4 (* 3 (* 2 (factorial 1))))))
(* 6 (* 5 (* 4 (* 3 (* 2 1)))))
(* 6 (* 5 (* 4 (* 3 2))))
(* 6 (* 5 (* 4 6)))
(* 6 (* 5 24))
(* 6 120)
720

To resolve this dilemma, rewrite your function in a tail recursive style using the special operator called recur, which according to the documentation, “does constant-space recursive looping by rebinding and jumping to the nearest enclosing loop or function frame.” This means that it tries to simulate a tail call optimization, which the JVM doesn't support. If you rewrite the preceding factorial example using this style, it looks something like the following:

(defn factorial2 [n]
    (loop [count n acc 1]
       (if (zero? count)
            acc
          (recur (dec count) (* acc count)))))

In this version of the factorial function, you can define an anonymous lambda expression using the loop construct, thus providing the initial bindings for the local variables count to be the value passed into the factorial function to start the accumulator at 1. The rest of the function merely consists of a conditional that checks the base case and returns the current accumulator, or makes a recursive call using recur. Notice how in the tail position of the function this program doesn't require the runtime to keep track of any previous state, and can simply call recur with the calculated values. You can trace the execution of this improved version of the factorial as seen here:

(factorial2 6)
(loop 6 1)
(loop 5 6)
(loop 4 30)
(loop 3 120)
(loop 2 360)
(loop 1 720)
720

The call to factorial2 take fewer instructions to finish, but it doesn't need to place new calls on the stack for each iteration, like the first version of factorial did.

But what happens if you need to perform mutual recursion? Perhaps you want to create your own version of the functions for determining if a number is odd or even. You could define them in terms of each other. A number is defined as being even if the decrement of itself is considered odd. This will recursively call itself until it reaches the magic number of 0, so at that point if the number is even it will return true. If it's odd it will return false. The code for the mutually recursive functions for my-odd? and my-even? are defined here:

(declare my-odd? my-even?)
(defn my-odd? [n]
  (if (= n 0)
    false
    (my-even? (dec n))))
(defn my-even? [n]
  (if (= n 0)
    true
    (my-odd? (dec n))))

This example suffers from the same issue found in the first example, in that each successive recursive call needs to store some sort of state on the stack in order to perform the calculation, resulting in a stack overflow for large values. The way you avoid this problem is to use another special operator called trampoline, and modify the original code to return functions wrapping the calls to your recursive functions, like the following example:

(declare my-odd? my-even?)
(defn my-odd? [n]
  (if (= n 0)
    false
    #(my-even? (dec n))))
(defn my-even? [n]
  (if (= n 0)
    true
    *(my-odd? (dec n))))

Notice the declare function on the first line. We can call the function using the trampoline operator as shown here:

(trampoline my-even? 42)

If the call to a function, in this case my-even?, would return another function, trampoline will continue to call the returned functions until an atomic value gets returned. This allows you to make mutually recursive calls to functions, and not worry about blowing the stack. However, we're still left with one problem. If someone wishes to use the version of my-even? and my-odd?, they must have prior knowledge to know they must call them using trampoline. To fix that you can rewrite the functions:

(defn my-even? [n]
  (letfn [(e? [n]
            (if (= n 0)
              true
              #(o? (dec n))))
          (o? [n]
            (if (= n 0)
              false
              #(e? (dec n))))]
    (trampoline e? n)))
(defn my-odd? [n]
  (not (my-even? n))) 

We've effectively hidden away the knowledge of having to use trampoline from our users.

Higher Order Functions

One of the many qualities that define a language as being functional is the ability to treat functions as first class objects. That means functions can not only take values as parameters and return values, but they can also take functions as parameters as well. Clojure comes with a number of commonly used higher order functions such as map, filter, reduce, remove and iterate, as well as providing you with the tools to create your own.

In Java, for example, if you want to filter a list of customers that live in a specific state, you need to create a variable to hold the list of filtered customers, manually iterate through the list of customers, and manually add them to the local variable you created earlier. You have to specify not only what you want to filter by, but also how to iterate through the list.

public List<Customer> filterByState(List<Customer> input, String state) {
     List<Customer> filteredCustomers = new ArrayList<>();
     for(Customer customer : input) {
          if (customer.getState().equals(state)) {
               filteredCustomers.put(customer);
          }
     }
     return filteredCustomers;
}

This Clojure example deals less with how to do the filtering, and is a bit more concise and declarative. The syntax may look a little strange, but you are simply calling the filter function with an anonymous function telling what you should filter on and finally the sequence you want to filter with.

(def customers [{:state "CA" :name "Todd"}
                {:state "MI" :name "Jeremy"}
                {:state "CA" :name "Lisa"}
                {:state "NC" :name "Rich"}])
(filter #(= "CA" (:state %)) customers)

One common design pattern that exists in object-oriented programming, the Command pattern, exists as a way to cope with the lack of first class functions and higher order functions. To implement the pattern, you first define an interface that defines a single method for executing the command, a sort of pseudo-functional object. Then you can pass this Command object to a method to be called at the appropriate time. The downfall of this is that you need to either define several concrete implementations to cover every possible piece of functionality you would need to execute, or define an anonymous inner class wrapping the functionality.

public void wrapInTransaction(Command c) throws Exception {
    setupDataInfrastructure();
    try {
        c.execute();
        completeTransaction();
    } catch (Exception condition) {
        rollbackTransaction();
        throw condition;
    } finally {
        cleanUp();
    }
}
public void addOrderFrom(final ShoppingCart cart, final String userName,
                         final Order order) throws Exception {
    wrapInTransaction(new Command() {
        public void execute() {
            add(order, userKeyBasedOn(userName));
            addLineItemsFrom(cart, order.getOrderKey());
        }
    });
}

In Clojure you have the ability to pass functions around the same as any other value, or if you just need to declare something inline you can leverage anonymous lambda expressions. You can rewrite the previous example in Clojure to look like this code:

(defn wrapInTransaction [f]
     (do
          (startTransaction)
          (f)
          (completeTransaction)))
(wrapInTransaction #(
     (do
          (add order user)
          (addLineItemsFrom cart orderKey))))

To put it another way, with imperative languages you usually have to be more concerned with how you do things, and in Clojure you're able to focus more on the what you want to do. You can define abstractions at a different level than what is possible in most imperative languages.

(def add2 (partial + 2))

(ns sampledb.data
  (:require [clojure.java.jdbc :as jdbc]))
(def spec {:classname "org.postgresql.Driver"
           :subprotocol "postgresql"
           :subname "//localhost:5432/sampledb"})
(defn all-users []
  (jdbc/query spec ["select * from login order by username desc"])))
(defn find-user [username]
  (jdbc/query spec ["select * from login where username = ?" username]))
(defn create-user [username password]
  (jdbc/insert! spec :login {:username username :password password :salt
    "some_salt"}))

(ns sampledb.data
  (:require [clojure.java.jdbc :as jdbc]))
(def spec {:classname "org.postgresql.Driver"
           :subprotocol "postgresql"
           :subname "//localhost:5432/sampledb"})
(def query (partial jdbc/query spec))
(def insert! (partial jdbc/insert! spec))
(defn all-users []
  (query ["select * from login order by username desc"])))
(defn find-user [username]
  (query ["select * from login where username = ?" username]))
(defn create-user [username password]
  (insert! :login {:username username :password password :salt "some_salt"}))

(defn apply-sales-tax [items]
  ((map (partial * 1.06) items)))

 (defn minify [input]
  (str/join (map str/trim (str/split-lines input))))

(def minify (comp str/join (partial map str/trim) str/split-lines))

Embracing Laziness

Clojure itself is not considered to be a lazy language in the same sense that a language like Haskell is; however, it does provide support for creating and using lazy sequences. In fact, most of the built in functions like map, filter, and reduce generate lazy sequences for you without you probably even knowing it. You can see this here:

user> (def result (map (fn [i] (println ".") (inc i)) '[0 1 2 3]))
#'user/result
user> result
.
.
.
.
(1 2 3 4)

When you evaluate the first expression, you don't see any output printed to the console. Had this been a non-lazy sequence, you would have seen the output printed to the screen immediately, because it would have evaluated the println expression at the time of building the sequence. Instead, the output is not printed until you ask Clojure to show you what is in the result symbol, and it has to fully realize what's inside the sequence. This is exceptionally useful, because the computation inside the function that you pass to map may contain some fairly expensive operation, and that expensive operation by itself may not be an issue. Yet, when the operation is executed, the execution of your application can be slowed by several or even hundreds of times.

Another useful example of a lazy sequence in action is when representing an infinite set of numbers. If you have a set of all real numbers, or a set of all prime numbers, you can set all of these numbers in the Fibonacci sequence as shown here.

(def fib-seq
     (lazy-cat [1 1] (map + (rest fib-seq) fib-seq)))
(take 10 fib-seq)
-> (1 1 2 3 5 8 13 21 34 55)

This sequence is defined using a lazy sequence, and next you will ask Clojure to give you the first 10 numbers in a sequence. In a language that did not support this level of laziness, this type of data modeling would simply not be possible.

Another example of how this can be useful is by infinitely cycling through a finite collection. For example, if you want to assign an ordinal value to every value in a collection for an example group of a list of people into four groups, you can write something similar to the following:

(def names '["Christia" "Arline" "Bethann" "Keva" "Arnold" "Germaine"
             "Tanisha" "Jenny" "Erma" "Magdalen" "Carmelia" "Joana"
             "Violeta" "Gianna" "Shad" "Joe" "Justin" "Donella"
             "Raeann" "Karoline"])
user> (mapv #(vector %1 %2) (cycle '[:first :second :third :fourth]) names)
[[:first "Christia"] [:second "Arline"] [:third "Bethann"] [:fourth "Keva"]
  [:first "Arnold"] [:second "Germaine"] [:third "Tanisha"] [:fourth "Jenny"]
  [:first "Erma"] [:second "Magdalen"] [:third "Carmelia"] [:fourth "Joana"]
  [:first "Violeta"] [:second "Gianna"] [:third "Shad"] [:fourth "Joe"]
  [:first "Justin"] [:second "Donella"] [:third "Raeann"] [:fourth "Karoline"]]

If you map over multiple collections, you will apply the function provided to the first item in the first collection, the first item in each successive collection, and then the second and so forth, until one of the collections is completely exhausted. So, in order to map the values :first, :second, :third, and :fourth repeatedly over all the names, without having to know how many names exist in the collection, you must find a way to cycle over and over repeatedly through the collection. This is what cycle and infinite lazy collections excel at.

When You Really Do Need to Mutate

Just because Clojure favors dealing with values doesn't mean you completely do away with mutable state. It just means you greatly limit mutable state, and instead use quarantine in your specific area of code. Clojure provides a few mechanisms to manage mutable state.

user> (def app-state (atom {}))
#'user/app-state
user> app-state
#atom[{} 0x1f5b7bd9]

user> (swap! app-state assoc :current-user "Jeremy")
{:current-user "Jeremy"}
user> app-state
#atom[{:current-user "Jeremy"} 0x1f5b7bd9]
user> (swap! app-state assoc :session-id "some-session-id")
{:current-user "Jeremy", :session-id "some-session-id"}
user> app-state
#atom[{:current-user "Jeremy", :session-id "some-session-id"} 0x1f5b7bd9]

user> (reset! app-state {})
{}
user> app-state
#atom[{} 0x1f5b7bd9]

user> (swap! app-state assoc :current-user "Jeremy" :session-id "some-session-id")
{:current-user "Jeremy", :session-id "some-session-id"}
user> (:current-user @app-state)
"Jeremy"
user> (:session-id @app-state)
"some-session-id"
user> (:foo @app-state :not-found)
:not-found

user> (def savings (atom {:balance 500}))
#'user/savings
user> (def checking (atom {:balance 250}))
#'user/checking
user> (do
        (swap! checking assoc :balance 700)
        (throw (Exception. "Oops..."))
        (swap! savings assoc :balance 50))
Exception Oops...  user/eval9580 (form-init1334561956148131819.clj:66)
user> (:balance @checking)
700
user> (:balance @savings)
500

user> (def checking (ref {:balance 500}))
#'user/checking
user> (def savings (ref {:balance 250}))
#'user/savings
user> (dosync
        (commute checking assoc :balance 700)
        (throw (Exception. "Oops..."))
        (commute savings assoc :balance 50))
Exception Oops...  user/eval9586/fn--9587 (form-init1334561956148131819.clj:6)
user> (:balance @checking)
500
user> (:balance @savings)
250

Nil Punning

If you're at all experienced in Java, you are very familiar with the dreaded NullPointerException. It's probably one of the most prolific errors encountered when developing in Java, so much so that the inventor of the Null reference, Tony Hoare, even gave a talk several years ago stating how big of a mistake it was (http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare). It seems odd that everything else, with the exception of primitive values, is an Object, except for null. This has led to several workarounds in languages, such as Optional in Java, null safe object navigation in Groovy, and even in Objective-C you send messages to nil and then just happily ignore them.

Clojure, being a Lisp, adopts the philosophy of nil punning. Unlike Java, nil has a value, and it simply means “no answer.” It can also mean different things in different contexts.

When evaluated as a Boolean expression, like many other dynamic typed languages, it will be equivalent to false.

user> (if nil "true" "false")
"false"

nil can also be treated like an empty Seq. If you call first on nil, you get a returned nil, because there is no first element. If you then call last on nil, you also unsurprisingly get nil. However, don't assume that nil is a Seq, because when you call seq on nil you will get a false return.

user> (first nil)
nil
user> (last nil)
nil
user> (second nil)
nil
user> (seq? nil)
false

Unlike many other Lisps, Clojure does not treat empty lists, vectors, and maps as nil.

user> (if '() "true" "false")
"true"
user> (if '[] "true" "false")
"true"
user> (if '{} "true" "false")
"true"

Because nil can take on many meanings, you must be mindful to know when nil means false and when it means nil. For example, when looking for a value in a map, the value for a key can be nil. To determine whether or not it exists in the map, you have to return a default value.

user> (:foo {:foo nil :bar "baz"})
nil
user> (:foo {:foo nil :bar "baz"} :not-found)
nil
user> (:foo {:bar "baz"} :not-found)
:not-found

Unlike Java, nil is everywhere and for functions return nil. Most functions are/should be written to handle a passed in nil value. “Using nil where it doesn't make sense in Clojure code is usually a type error, not a NullPointerException, just as using a number as a function is a type error.” (http://www.lispcast.com/nil-punning)

The Functional Web

It's interesting to see how web programming has evolved over the years. Many different paradigms have come and gone, with some better than others, and yet we haven't seen the end of this evolution. In the early days of the dynamic web back in the 1990s we saw technologies such as CGI, and languages such as Perl, PHP, and ColdFusion come into popularity. Then, with the rise of object-oriented programming, distributed object technologies such as CORBA and EJB rose up, along with object-centric web service technology such as SOAP, as well as object-focused web programming frameworks such as ASP.NET and JSF.

Recent years have seen a shift toward a more RESTful, micro-service based architecture. Nobody uses CORBA anymore, and even SOAP is a dirty word in many circles. Instead, web programming has started to embrace HTTP and its stateless nature and focus on values. Similar to how functional programming has gained popularity because of the rise in number of cores in modern day computers and the necessity of concurrent programming, the web also needs ways to deal with scaling horizontally rather than just vertically.

So what qualities, if any, does web programming in recent years share with functional programming? At its heart, your endpoints can be thought of as functions that take an HTTP request and transform them into an HTTP response. The HTTP protocol itself is also stateless in nature. True, there are things like cookies and sessions, but those merely simulate some sort of state through a shared secret between the client and server. For the most part, the REST endpoints can be thought of as being referentially transparent, which is why caching technologies are so prevalent.

That's not to say there aren't aspects of web programming that are not very functional. Obviously, it would be very difficult to get anything done without modifying some state somewhere. However, it seems like web programming shares as much if not more in common with functional programming than it does with object-oriented programming. In fact, you may find that there's much more opportunity for composability and reuse than with the component-based technologies that have fallen out of favor.

Polymorphic Dispatch with defmulti

Clojure, like many Lisps before it, takes a radically different approach to polymorphism by leveraging a concept called generic functions. This opens up a whole world of possibilities that just were not possible, and for the most part are still not possible, in object-oriented languages. In Clojure, you are not limited to runtime polymorphism on types alone, but also on values, metadata, and relationships between one or more arguments and more.

To rewrite our example above you would start by defining a generic function for area as shown here.

(defmulti area (fn [shape & _]
                 shape))

The generic function consists of first a name for the generic function, then a dispatch function to help Clojure figure out which implementation to call. In this case it's going to inspect the value of the first argument to our function. Then you can implement the various area functions for our different types of shapes like the following.

(defmethod area :triangle
  [_ base height]
  (/ (* base height) 2))
(defmethod area :square
  [_ side]
  (* side side))
(defmethod area :rectangle
  [_ length width]
  (* length width))
(defmethod area :circle
  [_ radius]
  (* radius radius Math/PI))

Here you've defined four implementations for the area function. You do this by, instead of defining them using defn, using the special form defmethod, followed by the name of the generic function, and the value from the dispatch function that you would like to match on. Notice how in the parameter lists for each of these functions, you can safely ignore the first parameter being passed in because it was only used for purposes of dispatch. You can see the actual usage of these below.

user> (area :square 5)
25
user> (area :triangle 3 4)
6
user> (area :rectangle 4 6)
24
user> (area :circle 5)
78.53981633974483

So, you may be wondering how this is any better than what we already have in object-oriented programming. Let's take a look at another example. Suppose you were creating a function that needed to apply a 5% surcharge if a customer lives in New York and a 4.5% surcharge if they live in California. You could model a very simplistic invoice as shown here.

{:id 42
 :issue-date 2016-01-01
 :due-date 2016-02-01
 :customer {:name "Foo Bar Industries"
            :address "123 Main St"
            :city "New York"
            :state "NY"
            :zipcode "10101"}
 :amount-due 5000}

Writing a similar method that handles this logic in Java would look something like the following.

public BigDecimal calculateFinalInvoiceAmount(Invoice invoice) {
     if (invoice.getCustomer().getState().equals("CA")) {
          return invoice.getAmount() * 0.05;
     } else if (invoice.getCustomer.getState().equals("NY")) {
          return invoice.getAmount() * 0.045;
     } else {
          return invoice.getAmount();
     }
}

In order to add another state that is needed to add a surcharge for, you must modify this method and add another else if conditional. If you wrote this example in Clojure, it would look like the following.

(defmulti calculate-final-invoice-amount (fn [invoice]
                                           (get-in invoice [:customer :state])))
(defmethod calculate-final-invoice-amount "CA" [invoice]
  (let [amount-due (:amount-due invoice)]
    (+ amount-due (* amount-due 0.05))))
(defmethod calculate-final-invoice-amount "NY" [invoice]
  (let [amount-due (:amount-due invoice)]
    (+ amount-due (* amount-due 0.045))))
(defmethod calculate-final-invoice-amount :default [invoice]
  (:amount-due invoice))

Now, if sometime in the future you decide to add a surcharge to another state, you can simply add another defmethod to handle the logic specific to that case.

Defining Types with deftype and defrecord

If you come from a background in object-oriented languages, you may feel compelled to immediately start defining a bunch of custom types to describe your objects, just as you would if you were designing an application in an object-oriented language. Clojure strongly encourages sticking to leveraging the built in types, but sometimes it's beneficial to define the data type so you can leverage things like type-driven polymorphism. In most programs written in object-oriented languages, the classes you define generally fall into one of two categories: classes that do interesting things, and classes that describe interesting things.

For the first of these things Clojure provides you with the deftype, and for the latter you can use defrecord. Types and records are very similar in how they're defined and used, but there are some subtle differences (see Table 1.1).

Before looking at how to define and use deftype and defrecord, you must first look at protocols.

Protocols

If you're at all familiar with Java, you can think of protocols as being very similar to interfaces. They are a named set of functions and their arguments. In fact, Clojure will generate a corresponding Java interface for each of the protocols you define. The generated interface will have methods corresponding to the functions defined in your protocol.

So, let's revisit the Shapes example from earlier. If you create a protocol for Shapes, it looks something like the following.

(defprotocol Shape
  (area [this])
  (perimeter [this]))

Next, create records for Square and Rectangle that implement the protocol for Shape as shown here.

(defrecord Rectangle [width length]
  Shape
  (area [this] (* (:width this) (:length this)))
  (perimeter [this] (+ (* 2 (:width this)) (* 2 (:length this)))))
(defrecord Square [side]
  Shape
  (area [this] (* (:side this) (:side this)))
  (perimeter [this] (+ (* 4 (:side this)))))

Then create and call the functions to calculate the area as shown here.

user> (def sq1 (->Square 4))
#'user/sq1
user> (area sq1)
16
user> (def rect1 (->Rectangle 4 2))
#'user/rect1
user> (area rect1)
8

Alternatively, you can also create your records using the map->Rectangle and map->Square functions as shown here.

user> (def sq2 (map->Square {:side 3}))
#'user/sq2
user> (def rect2 (map->Rectangle {:width 4 :length 7}))
#'user/rect2
user> (into {} rect2)
{:width 4, :length 7}
user> rect2
#user.Rectangle{:width 4, :length 7}
user> (into {} rect2)
{:width 4, :length 7}
user> (:width rect2)
4
user> (:length rect2)
7
user> (:foo rect2 :not-found)
:not-found

Also, recall that earlier records were discussed, which are basically wrappers around PersistentMap. This of course means that you can interact with your records as if they were maps in Clojure. You can access the members of your Rectangle object just as if it were a map, and you can even construct new maps from it using into.

Reify

Sometimes you want to implement a protocol without having to go through the trouble of defining a custom type or record. For that, Clojure provides reify. A quick example of this can be seen here.

(def some-shape
  (reify Shape
    (area [this] "I calculate area")
    (perimeter [this] "I calculate perimeter")))
user> some-shape
#object[user$reify_____8615 0x221f1bd "user$reify_____8615@221f1bd"]
user> (area some-shape)
"I calculate area"
user> (perimeter some-shape)
"I calculate perimeter"

You can think of reify as the Clojure equivalent of doing anonymous inner classes in Java. In fact, you can use reify to create anonymous objects that extend Java interfaces as well.