Immutability: The art of challenge the Universe

When in an object-oriented context come to my mind the word “Immutability” it’s very interesting because the first thought is one of the Seven Principles of the Order of the Universe, everything changes; nothing is stationary. Such principle happens in almost everything around us, economy, a chair, or the Nature. But after that something else invade my mind. In computer science and software engineer several aspects reflect our world, in some way.

Image:kejsirajbek in https://wallhere.com/

Immutability is associated to an object or phenomena that have the characteristic of being Immutable. This last sentence doesn’t say too much, :D . But What means be immutable? Well, our friend Google and Cambridge Dictionary say:

“Immutable(adjective): not changing, or unable to be changed”

In the object-oriented programming(OOP) and functional programming this concept is a reference to an object that cannot be modified after it is created. To be honest, the first time that I heard this concept sounds weird to me. Maybe because at that moment I was more familiar with object that are mutable. But I have something even more weird.

It’s very common hear from people when they are asked by “Object-Oriented Programming Principles” that almost always mention the following concepts:

• Encapsulation

• Abstraction

• Inheritance

• Polymorphism

But from words of Alan Kay, object-oriented programming pioneer he says:

"Object-oriented Programming to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

In other words, according to Alan Kay, the essential ingredients of OOP are:

• Message passing

• Encapsulation

• Dynamic binding

If we decide to combine “message passing” and “encapsulation” something important come up:

Avoiding shared mutable state by encapsulating state and isolating other objects from local state changes. The only way to affect another object’s state is by asking that object to change it by sending a message, but not commanding do it.

In resume, we need that avoid change the state of an object. So, Immutability is one of the core concepts inside the OOP that almost everyone never mention.

Immutable data types

Maybe at this point you are thinking. And what is the use of an object being immutable? Well, I have an example. Years ago, I developed a project and in such project was needed create a custom cache system. In the solution, the objects that stored the cached state were immutable.

Although this concept seems to be something hidden, in fact it is something that has been present in some programming languages ​​for a long time. For instance, C# contains the string data type. In this data type, behind the scenes acts like an immutable object. If we do an operation over the string, we get a new string but modified. And if you are wondering, what happens to the previous one? The garbage collector will handle it, eventually.

But the .NET Platform did not limit this concept to language aspect. From any .NET framework that support .NetStandard 1.0 and later, its available to the developers data collections with this behavior. These collections are designed to return a new version in every modification. Some of it are:

1. ImmutableArray

2. ImmutableDictionary

3. ImmutableList

4. ImmutableStack

And many others. In some of its Garbage Collector runs much more often than it mutable version, so be careful.

Beside all this, C# bring to us something else. The language designers of C# 9.0 added a special keyword called “record” to define a reference type that provides built-in supporting immutable data models. When we create a record, we are defining a new reference type that cannot be modified after it is created. In other words, we are defining an immutable type. Let see an example:

public record Vector3D
{
    public Vector3D(float x, float y, float z)
    {
        X = x;
        Y = y;
        Z = z;
    }
    public float X { get; init; }
    public float Y { get; init; }
    public float Z { get; init; }
}

Beside the “record” keyword you can notice the “init” keyword in the property definitions. This specify that the property can be assigned only in the initialization of the object. So, thanks to this language feature we won’t allow the object to be modified after the initialization, no matter who is using it.

When Microsoft published this feature, some people started to ask if this is necessary. Well, this is my point of view. Besides the previous Alan Kay words, we must always create tools that should be coherent to avoid a wrong us of it. In the code sample I defined the reference type called Vector. In Math, a vector is a unique entity inside a Vectorial Space. In other words, if someone decide to change any component value this action represent another vector, a new one with this modification. And with this behavior we can keep its math definition.

Several are the concepts in computer science that come from the word around us. But some of it doesn’t. Immutability is clear that doesn’t belong to the Nature. However, we can give it live among us as developers. Perhaps not only to allow us to define a better code, but also to try to express a wish in the Universe.