I read this great blog entry on programming against abstractions in clojure. You should go and read it. It is pretty good. The main idea is that one shouldn’t program against implementation but against an abstraction.

Now, doing that in OOP is very easy since, depending on the language that you use there may be abstract classes or interfaces, which are templates for how to build objects but won’t build an object directly.

The important principle to remember is that the function is the abstraction. 


OOP programmers have two mental blocks that work against them. The first one is that there is this often equivalence between method and function. In terms of syntax and what kind of work they do this is correct. From a more theoretical OOP perspective this is wrong.

What a method does in an object is semantically very different from a function.

A function operates under the mathematical function metaphor. If you give one kind of input you will get a specific output. The oop metaphor is that you have organisms, cells, actual physical objects that you can ask, send messages, and then they respond to it.

A method is meant to be something like the vocabulary of the object to handle certain messages. When we write something like

pacman.move(Direction.Right);

<

p>What we ought to be thinking is “Tell pacman to move to the right.”. Then the pacman object will check its vocabulary to see if it knows how to respond to “move”.

Functions should be treated as black boxes where you put input on one side and you get output from the other. You shouldn’t care how that is done as long as it returns what we expect.



This is not the case in clojure. I felt a bit at loss when I tried to figure out how to do it, but then it happens that the solution was simple. I will discuss that tomorrow.