The use of immutability

Question

Immutability

1. What are the advantages and benefits, when to use and why to use immutability in my projects?
2. The complexity of the implementation x time, worth it?
3. When I should not use immutability and what are the disadvantages?
4. What "good" practices should I consider when implementing immutability, that is, if there are?

Answer 1

One can understand a little about immutability in another question here on the website.

It only ensures that the state will never be changed on the same object. It does not guarantee that a variable always has the same value. This is an important distinction. It uses a technique of COW (here).

Includes any structures that only allow reading after their creation.

We’re not talking about constancy.

Also do not understand immutability as something that ensures that the object will never be altered in memory. This is a guarantee that the application compiled and executed, under normal conditions, will have the data preserved by it, nothing more than this.

What are the advantages, when should I use and why should I use immutability in my projects?

• Greatly facilitates the use of threads, After all if the state never changes all algorithms are free to access the objects without worries of being changed midway or of changing them and causing problems to other parts of the application. Facilitates competition and parallelization. Are free of side effects. That is, sharing is free;
• It is great as a key to diverse data structures in many applications. Mutable keys are always complicated to manipulate because a change in the object that was used as a key can change the entire data structure;
• can be cached with no major worries, the object has unique state;
• the codes are easier to follow. State change has always been the biggest complicator of programming, eliminating this eliminates complexity and avoids bugs;
• Testing immutable objects is easier;
• immutable objects can be considered automatically atomic, consistent and isolated, characteristics that ideally every object should possess;
• they have a durability in the sense that they are never overlapped, the original information is always available. Of course this does not mean that it is permanent. If there are no references to the object they can be discarded. And obviously there is no permanent durability in temporary storage devices, as is the case with RAM (other than NVRAM);
• how state it is that several references to the same object can save memory avoiding having copies with repeated data. This can be advantageous in some scenarios of large duplication of objects of the same identity.

The complexity of the implementation x time, worth it?

Pure opinion, depends, I don’t know, only you know for your case.

If it were that silver bullet all that some think, everyone would be doing everything immutable. This does not occur in most applications.

When I must not use immutability?

• The main reason is the cost of keeping these structures active. To ensure immutability the copy of objects is necessary in all operations that write in any part of their state. Whenever there is a writing, a new object needs to be created. This is expensive in both processing and memory consumption, and some objects are absurdly large. Whether it pays this price depends on every need;

• the copy of the object can trigger an absurd amount of copies of other objects, because the creation of a new object possibly results in the state change of another object;

• can be worse, objects can have cyclical references preventing its use;

• the copy algorithm can still have a development cost and maintenance difficulty in cases where the copy is not a trivial process that can be easily automated in its implementation;

• if the language doesn’t help (it’s getting rare) it may not be so simple to implement immutability;

• cannot use when the object needs to be unique or cannot have indiscriminate copies in the application. The most typical case is the object creation Singletons or any similar pattern. Example:

  Imagine a current account balance that receives a withdrawal, then another object is created because of immutability. At the same time another withdrawal is made, which creates another object based on the first but not the copy generated now. You can already see that the account will not close, right? A coordination will be necessary, what seemed simple is no longer so simple;

• Remember that the mental model that we have of most objects is that its characteristics can be changed instead of creating a new object when it needs a different feature. Adapting the mental model to the paradigm is not usually ideal. Let’s face it, imposing something on a team that doesn’t work well with this can be disastrous. The best tool is the one you know. Example:

  It might be weird to say that João is someone else because now he’s had a pay rise. Immutability demands this, and worse, the original John continues to exist. It happens to have a poor John and a rich clone ;) it does not reproduce what actually happens in the real world.

  Of course there are solutions to these problems, but then we started to complicate the design of the application and we begin to wonder if it compensates.

What I should mainly consider when using immutability?

Can I think? I don’t know yet. Besides everything I’ve written I’d need to think.

Pay attention to the complexity of immutable data structures. To optimize and avoid the full copy of the entire structure it is common to adopt an internal structure that changes the complexity (Big O) that the developer usually expects from that structure. To avoid copies it is possible for an array or a stack to turn a linked list or tree, or at least make use of these structures in a complementary way.

Completion

I know little about DDD but it seems to me to be a methodology that defines some rules for adoption of each case.

It has to weigh well, I can not give definitive conclusions. And it is not ideal to adopt a unique form. In most scenarios it is usually better to decide on this, structure by structure and not adopt a form for every project.

Do not consider this answer as definitive on all aspects. The question is a little broad and I do not think it would fill with details. I didn’t even do a deep search to analyze everything I could. I certainly forgot important things.