Who is afraid of immutable data?
Anand Kumar Keshavan Founder/Partner Swanspeed Consulting
Lately, my LinkedIn feed has been getting posts about events on functional programming with special emphasis on how to deal with immutable data .
True, many programmers are puzzled when told that from now onwards you shall not modify the value of a variable once it has been initialised. "But how can I work with loops? Doesn't incrementing a counter need the value of a counter to be changed?" This is just the result of doing something over and over again and can be overcome by learning some programming techniques such as recursion and map/reduce over collections. The larger problem, however, lies with the questions of the following nature: "What about real world things like account balances ? How do I change the account balance of I am not allowed to change the value?". ( To be fair to programmers who are new to the functional world , such questions have been raised by some eminent thought leaders in YouTube videos while expressing their reservations about functional programming)
This post addresses the second class of questions, as these represent some fundamental questions about the way we look at application domains.
What I am about to say might come as a surprise to many programmers, but this has been obvious to accountants and finance professionals for centuries. In the real world, transactions are immutable. When we deposit money into a bank account, the transaction cannot be changed.. we cannot go back in time and change the amount we deposited into the bank. This is so obvious and banal that we don't even consciously think about it anymore. The only way to change the transaction is to create another transaction which negates the the first one. If we one could change the transaction by any other means, one's bank balances will have no integrity or meaning. Like I said, accountants have known this for centuries and literally wrote the book on this topic. ( Perhaps that is the reason they rule the world!!) This is true for ordering a device from Amazon or one's attendance data at school or a work place.
In the real world there is a temporal angle to objects such as accounts and balances. When one says that " my account has a balance of Rs. xxx", one means that "my account has a balance of Rs. xxx at time(t), where t is the current time. But one may have a different balance at another time(t), say last Monday. The important thing to note here is that for a given account "a balance at time(t)" is immutable. Therefore a a function such as getBalanceAt(Time t) will be a pure function i,e, each time you call it it will return the same value. This property also makes the function referentially transparent. Both properties are foundational elements of functional programming.
Okay, let us model the aforesaid account/ balance problem using immutable data types. Normally, I would use a functional language such as Scala or Haskell, but in this case I have used Java ( yes, plain old Java that too,, none of the functional extensions in Java 8). Why? Because it will be comprehensible to a larger audience and Scala/Haskell programmers probably don't have a problem with immutability anyway.
Unfortunately, trying to do this in Java we run into a problem almost immediately- the data structures such as ArrayList<T> in Java are mutable. One could use collections.unmodifable() function to make lists immutable. But the interface is clunky and unwieldy. Therefore here is a basic immutable lisp-like list class:
We need another class to model time. Here is a fairly simple implementation that simulates time as an ever increasing integer ( increases by 10 each time next() is called. These kind of objects are required to write automated tests. In real programming scenarios, one might consider dependency injection of the a class that models time- but that is not really within the scope of this post.
The ITime also has equals, lessThan, greaterThan... comparison operations, although we use just use one of them in our Account() class.
Alright, back to our Account/Balance problem.
An account has :
- an Opening balance
- A list of transcations
- and most importantly a time element
The snapshot of an account at any given point of time is immutable-- its opening balance( same at every point in time), List of transactions, which is constant for any specific point in time and so on.
Here are the classes that mirror the Transaction entities and are straight forward OO representations.
Our account has a list of Transactions. The class hierarchy given above, models debit/credit transaction types. Please note that each transaction has a time element. Also the values of time and amount are declared to be final, making them immutable. There is a function called getComputationalValue() that seems kind of out of place. For Debit transactions it returns the negative value for the amount , while for Credit() transactions it returns a positive value. This is used to model the idea that a debit() reduces the balance, while a credit() increases the balance. This is not the ideal way to model these concepts- but for the purposes of this post, which is about immutability, this should be fine.
And here is the Balance type which represents the balance at a point in time.
As straight forward at it gets. The purpose of this object is to define the signature of getBalance() functions in the Account class. These functions, as you shall see, always return a "balance at" some "time". Internally, the balance for an account is maintained as a double.
And finally, the Account() class:
Here are some salient points about this class:
- all data members are immutable
- all constructors are private- clients can construct an account only by calling the factory type static function open(). ( This is very close to the domain-- you can only create an account by opening it, right?)
- it allows two operations "debit" and "credit" which also closely model the domain. Both these functions retuning a Optional<Account> where, if present, the Account() has new value for time. If you see the underlying private function, applyTransaction() , it returns a new Account with the updated transaction list
- Transactions, once added cannot be removed by the client of this class. Within the class, they can go to the previous snapshot by "subtracting" the current transaction.
- The private function snapshotAt Time ( t) gives us the snapshot of the account for a given value of t.
- the public function getBalance() returns the latest balance.
- the public function getBalanceAt(t) returns a the balance at some time t.
Due to its immutable nature one can reason about an Account object. The opening balance plus the sum of all transactions will always be equal to the balance. This is an equation and one can write a self verifying function which assures this after each transaction. Similarly, the reverse operation is also true. If you subtract all the transactions from the current balance one you will get the opening balance. What happens if you maintain two copies of this account, where one of the copies verifies using the first technique and the other one using the second technique? You get something very similar to a very elementary type of blockchain.
Modelling domain types as immutable elements ( which, in all probability are, in real life) has great benefits. It allows one to reason about the functions and test them with more precision. Also, without immutability, one is likely to get into some serious trouble if one tries to move into concurrency. Unfortunately, some of the foundational elements of any tech stack, RDMSs, for example, do not support immutability, a legacy from a time when storage was expensive. A lot of checks and balances have to be created to overcome this limitation of storage software. The newer databases such as Datomic support immutability out-of-the-box. One hopes that in the near future, such ideas will propagate to the mainstream DBMS software.
[This is not the best way to implement these kinds of types in a functional language such as Scala, for there are much more elegant ways of doing so. The purpose of this post is to help the reader to cross the mental barrier of immutability! ]