The Functional Way of Things

In my last post, I talked about how closures instrument a way to package behavior encapsulating state; instead of dumb(mute, not stupid) objects encapsulating state and behavior.

Before I go on to how closures enable this changed train-of-thought (in the next post), I thought it best to discuss this paradigm shifting way to address programming.

Object oriented approach

Client :     Hey I need my pencil sharpened.

Service :  I can help you. Here's a sharpener. You can use it to sharpen your pencil.

Client :     Uh OK. I'll just find the method on that to sharpen my pencil.

Function oriented approach

Client :     Hey I need my pencil sharpened.
Service :  I can help you. Here's the ability to sharpen. :)
Client :    Cool ! I can directly use that to sharpen my pencil.

To truly think in a functionally oriented way, the thought shift is one that requires us to think in a plane that is beyond our normal plane of thought.
In this physical world we cannot help but use objects as the boundaries of things. We recognize that a sharpener is different from a chair because of their appearance and ability to sharpen and ability to be sat on.

And up till now we have designed our applications to reflect this perception of reality. Our account objects, customer objects and sharpener objects reflect the boundaries of things in a program.

But functionally oriented programs can go beyond that. One step beyond what is defined in the physical realm. Being able to define boundaries at a finer level - namely behavior and abilities - allows developers to have greater control over what is exported.


Object oriented approach
Client : Hey service thanks for the sharpener. I see that it has some dimensions, color, a handle, blades and a mechanism for rotating them. Hmm I can't seem to access those.
But hey ! Here's the sharpen method. I can use that. It'll probably use some or all of these other things, but I don't care. My pencil is sharpened.

Function oriented approach
Client : Hey service thanks for the ability to sharpen. I can use it to sharpen my pencil. I don't care how it did it or what it used to do it. My pencil is sharpened.


In the object oriented way of things, the fact that the client doesn't care about the implementation details is implemented by visibility.  By hiding whatever the developer thinks the client doesn't need to know, the developer only exposes the behavior as the said public API.
But the point is that whatever is exported is still an object !
An object with identity, an object with state(relevant and irrelevant), an object with a plethora of behavior, an object which just seemingly happens to have the behavior the client actually wanted in the first place.

Of course you could give a minified version of the object back to the client with just the required behavior and related state, but that's just a bad way. It could break in a lot of ways.

It's like removing a filer from a Swiss army knife and giving that to the client, because that's the only thing he's interested in.
Of course this was a bad example... for a reason - as I mentioned, you can't apply the functional approach to the real world. You can never be handed the ability to sharpen, or to file, or to learn new things (though I understand this is possible in The Matrix). If that were possible no one would attend school.

So in the functional way of things, the export is the actual behavior the client needs. Two things can happen here.

1. The function is stateless and only operates on it's parameters.
2. The function requires state and the relevant (and only the relevant) state is bundled along with it. (Closure)

Of course if the client wanted the object itself, you could return the object. But now we have finer grain of control over what we export.


In summary, functional approach is really changing the way we link up modules and choose what to export.

In the next post I will talk about how closures facilitate the Functional Way of Things...