Need advice/idiom to reduce number of parameters in functions

230 views
Skip to first unread message

Chris Wong

unread,
May 13, 2015, 12:58:39 AM5/13/15
to clo...@googlegroups.com
I have a set of functions that need a map of historic data.  Hence, this map gets passed along from function to function, usually several levels deep. In addition to the map, a reference date also frequently get passed along in 80% of the API.  Sometimes a third or fouth parameter is also passed along several layer in addition to function specific parameters. You got the idea. In OOP, these common function parameters usually are part of the object's attributes. In FP, I've seen them passed along individually or packaged up into a map or vector so that they are easy to pass along... sort of like a context object getting passed around.

What's the Clojure's way or FP way to improve this without having 5+ parameters in almost every function?

Thanks
Chris


Herwig Hochleitner

unread,
May 13, 2015, 9:38:43 AM5/13/15
to clo...@googlegroups.com
In functional programming you can do a similar thing as in OOP: Define your functions as closures that can access common arguments via lexical scope. So instead of creating a context object, you create functions:

(defn make-context [some context parameters]
  {:op1 (fn [x] ...)
   :op2 (fn [y] ...)})

The clojure-specific variant are protocols, e.g.:

(defn make-context [some context parameters]
  (reify ContextProtocol
    (op1 [_ x] ...)
    (op2 [_ y] ...)))

They have the advantage of better type checking + defrecords to retain visibility into those context parameters.

Hope that helps

David James

unread,
May 13, 2015, 10:12:13 AM5/13/15
to clo...@googlegroups.com
Well, this is question many people ask. :) It is a matter of tradeoffs:
  • Too many arguments may be an aesthetic problem. It may also reflect a design problem; you might be able to rethink a system to simplify it. (What "too many" means is debatable.)
  • With many arguments, you may choose to combine them as a map. Then you can destructure the ones you need. Risks: you may (a) lose clarity as to what arguments are used; (b) miss out on memoization opportunities.
  • Having ~4 to ~6 arguments may not be as bad as you think. First, it provides clarify into what the function needs. Second, memoization is easier. In summary, it may be better than the alternatives!
Reply all
Reply to author
Forward
0 new messages