Creating Custom Higher-Order Functions

A custom higher-order function should earn its place in the codebase.

The goal is not to prove that functions can take other functions. The goal is to capture a repeated pattern clearly enough that future readers understand the program faster.

For Java developers, this is the same discipline you already apply to classes and interfaces: introduce an abstraction when it names a real idea, not merely because the language makes it possible.

The Rule Of Thumb

Create a custom higher-order function when all three are true:

• the traversal or control shape repeats
• the varying behavior can be expressed as one or more function arguments
• the new function name adds domain meaning

If the function only renames map, filter, or reduce, it is probably not worth adding.

A Weak Wrapper

This function technically accepts a function, but it does not improve the code:

1(defn apply-to-each [f coll]
2  (map f coll))

Most readers would rather see:

1(map normalize-order orders)

The direct version is shorter and clearer. apply-to-each hides a familiar core function without adding domain meaning.

A Better Custom Function

Now compare that with a function that captures a real business pattern.

Suppose several parts of your system need to validate entities and return structured failures instead of just true or false.

1(defn validate-with [rules entity]
2  (->> rules
3       (keep (fn [{:keys [id pred message]}]
4               (when-not (pred entity)
5                 {:rule/id id
6                  :rule/message message})))
7       (into [])))

The callers provide rule functions:

 1(def order-rules
 2  [{:id :has-customer
 3    :pred :order/customer-id
 4    :message "Order must have a customer"}
 5   {:id :positive-total
 6    :pred #(pos? (:order/total %))
 7    :message "Order total must be positive"}])
 8
 9(validate-with order-rules {:order/total 0M})
10;; => [{:rule/id :has-customer, :rule/message "Order must have a customer"}
11;;     {:rule/id :positive-total, :rule/message "Order total must be positive"}]

This higher-order function is worth having because it names a repeated workflow:

• walk rules
• run each predicate
• collect structured failures

That is more than a wrapper around map.

Design The Function Contract First

Before writing the code, decide what the callback receives and returns.

That contract is more important than the implementation trick.

Name Function Arguments By Role

Names like f are fine for tiny examples, but production functions often benefit from role names:

1(defn summarize-by [key-fn value-fn coll]
2  (reduce (fn [summary item]
3            (update summary (key-fn item) (fnil + 0M) (value-fn item)))
4          {}
5          coll))

The names tell you the contract:

• key-fn decides the grouping key
• value-fn decides the numeric value to add
• coll is the data being summarized

Usage stays readable:

1(summarize-by :order/status :order/total orders)

Keep The Data Argument Last When It Helps

Clojure code often puts the main collection last because it composes well with threading macros and partial application.

1(->> orders
2     (filter :order/paid?)
3     (summarize-by :order/status :order/total))

This is not an absolute law. It is a convention that often improves pipeline readability.

Java Comparison

In Java, a similar abstraction might become:

• a class with a strategy field
• a method accepting Function, Predicate, or BiFunction
• a stream collector
• a reusable service method with lambdas

Clojure usually starts with a function because the abstraction is about behavior, not object identity.

That is the migration skill: choose the smallest abstraction that honestly names the behavior.

A Review Checklist

Before keeping a custom higher-order function, ask:

Knowledge Check