Question

I’m trying to figure out whether Clojure is something that can fully replace the paradigms that I’m used to in other languages. One thing that I don’t understand is how to idiomatically achieve encapsulation in Clojure (by encapsulation I’m referring to the bundling of data with the methods (or other functions) operating on that data).

Here is a use case from OOP:

var apple = {
    type: "macintosh",
    color: "red",
    cost: 5
    markup: 1.5
    getInfo: function () {
        return this.color + ' ' + this.type + ' apple';
    }
    getPrice: function(){
        return this.cost * this.markup;
    }
}

OR similarly:

var person = {
    birthdate: '8/30/1980',
    firstname: 'leeroy',
    middleinitial: 'b',
    lastname: 'jenkins',
    getAge: function () {
        return -(new Date()
 - new Date(this.birthdate));
    }
    getFullFormattedName: function () {
        return capitalize(this.firstname+' '+this.middleinitial+' '+this.lastname;
    }
}

It’s often convenient to bundle the behavior with the data in this way, but what is the idiomatic way that Clojure allows this problem to be solved?

Answer 1

In idiomatic clojure your functions do not belong to data, they operate on these data. In place of structures maps or records are used, and you define functions which take these structures as parameters. For example, your apple example could look like this:

; Define a record type with given fields
; `defrecord` macro defines a type and also two constructor functions,
; `->apple` and `map->apple`. The first one take a number of arguments
; corresponding to the fields, and the second one takes a map with
; field names as keys. See below for examples.
(defrecord apple [type color cost markup])

; Define several functions working on apples
; Note that these functions do not have any kind of reference to the datatype,
; they exploit map interface of the record object, accessing it like a map,
; so you can supply a real map instead of record instance, and it will work
(defn get-info [a] (str (:color a) " " (:type a) " apple"))
(defn get-price [a] (* (:cost a) (:markup a)))

; Example computation
; Bind `a` to the record created with constructor function,
; then call the functions defined above on this record and print the results
(let [a (->apple "macintosh" "red" 5 1.5)
      a-info (get-info a)
      a-price (get-price a)]
  (println a-info a-price))
; Will print the following:
; red macintosh apple 7.5

; You can also create an instance from the map
; This code is equivalent to the one above
(let [a (map->apple {:type "macintosh" :color "red" :cost 5 :markup 1.5})
      a-info (get-info a)
      a-price (get-price a)]
  (println a-info a-price))

; You can also provide plain map instead of record
(let [a {:type "macintosh" :color "red" :cost 5 :markup 1.5}
      a-info (get-info a)
      a-price (get-price a)]
  (println a-info a-price))

Usually you use records when you want static object with known fields which is available from Java code (defrecord generates proper class; it also has numerous other features, described at the link above), and maps are used in all other cases – keyword arguments, intermediate structures, dynamic objects (e.g. the ones returned from sql query) etc.

So in clojure you can think of namespace as a unit of encapsulation, not data structure. You can create a namespace, define your data structure in it, write all the functionality you want with plain functions and mark internal functions as private (e.g. define them using defn- form, not defn). Then all non-private functions will represent an interface of your namespace.

If you also need polymorphism, you can look into multimethods and protocols. They provide means for ad-hoc and subtyping kinds of polymorphism, that is, overriding function behavior – the similar thing you could do with Java inheritance and method overloading. Multimethods are more dynamic and powerful (you can dispatch on the result of any function of the arguments), but protocols are more performant and straightforward (they are very similar to Java interfaces except for inheritance and extendibility).

Update: a reply to your comment for the other answer:

I am trying to determine what the approach that replaces methods of
OOP

It is helpful to understand what exactly ‘methods of OOP’ are.

Any method in conventional object-oriented language like Java or especially C++ essentially is a plain function which takes an implicit argument called this. Because of this implicit argument we think that methods “belong” to some class, and these methods can operate on the object they are “called on”.

However, nothing prevents you from writing friendly global function (in C++) or public static method (in Java), which takes an object as its first argument and performs all the things which are possible to do from a method. No one does this because of polymorphism, which is usually achived with the notion of methods, but we are not considering it right now.

Since Clojure does not have any notion of ‘private’ state (except for Java interop functionality, but that is completely different thing), functions do not need to be connected in any way with the data they operate on. You just work with the data supplied as an argument to the function, and that’s all. And polymorphic functionality in Clojure is done in different way (multimethods and protocols, see the links above) than in Java, though there are some similarities. But that’s the matter for another question and answer.