Clean Architecture — Functional Programming

A chapter in which Uncle Bob tells us more about the functional programming paradigm.

About this article

This is a part of my series of articles where I go chapter-by-chapter through the “Clean Architecture” by Robert.C.Martin and share my thoughts, analysis and pieces of knowledge I’ve gathered. Previous part can be found here.

“low angle photography of building” by Felix on Unsplash

Immutability

Immutability is the basis of functional programming, it’s what makes this paradigm so useful and so different from others. In a truly functional programming language, variables can be initialized but never ever modified or reassigned.

For example, a simple loop that prints the first squares of the first 25 integers in Java would look like this:

for (int i=0; i<25; i++){
    System.out.println(i*i)
}

Notice how value of i changes with each iteration, that’s mutablity. In functional language (Clojure in this case) it would go like this:

(println (take 25 (map (f[x] (* x x)))))

Notice that in Clojure we do not change the value of any of the variables, we just consume a ‘stream’ of 25 integers and map every one of them with a square function. That’s how immutability looks like in practice, thanks to this we don’t have to worry about the state that our system is in right at the moment. Everything has to behave the same way every time we run our function.

This leads us to a surprising statement: Variables in functional languages do not vary.

Immutability in architecture

As cool as immutability might sound like for software architects, no race conditions and no problems with concurrent update sound pretty great after all, it’s not that practical in real life. In case of real systems, both memory and processing speed limits must be taken into consideration.

If we want to keep every variable separately and never update any of them, it’s going to take up a lot of memory. If we want to recalculate some value every time we need this value, it’s going to cost us a lot of processing power.

That’s why in real systems people tend to segregate code modules into mutable and immutable components. The immutable components communicate with other components which in turn change the state of variables. To avoid all the quirks and annoyances that modification brings with itself, mutable components often some kind of transactional memory.

Immutable components are usually responsible for most of the application’s business logic and the mutable ones are stripped to just read/write operations as much as it is possible.

CR > CRUD

Let’s now imagine a database with no data. Instead of rows and columns of information, this database would store transactions. Whenever someone wants to get some data out of it, this data would have to be recalculated from the very first transaction.

This glorious image is hard to achieve for now, memory and processing limitations make it very hard to implement and in the long run this kind of database would take up much more memory than the regular, mutable one. However, there are ways around these restrictions and limitations. If we could only make implementation of such systems profitable and easily achievable in real life, it would become possible to create entirely functional applications.

Noting would get updated or deleted, data could be just created or read. That’s how our good old CRUD could become just CR. Maybe in a few years this dream will come true, it would make so many operations on databases so much easier. But for now it’s just a beautiful dream.

Summary

I encourage you to share your feedback and point of view with me, it’s the best way for all of us to learn and grow. Also, check out the complete book, it’s a really wonderful source of knowledge for any developer. My articles are just a shallow summary of information that can be found in this book, do yourself a favor and read it all!