[TIL-2] Immutability of an object
Recently, I got a question about “what is an immutable object?”. Back then, I only knew that immutable objects meant that the object cannot be changed.
After I answered like that I got a follow-up question,” so the final keyword is immutable ?”. And then I said “yes I guess, but I’m not sure”
Driven by curiosity. I read sources at other websites and make my understanding make sense.
What is Immutability?
An immutable object is an object whose internal state remains constant after it has been entirely created.
In real life project, an immutable object guarantees us that it will behave in the same way during its whole lifetime. In real-life projects, the API gives us only read-only methods, it should never include methods that change the internal state of the object.
What are the differences between an immutable object vs a final object?
- final means that you can’t change the object’s reference to point to another reference or another object, but you can still mutate its state (e.g using setter methods). Whereas immutable means that the object’s actual value can’t be changed. However, you can change its reference to another one.
- The final modifier is applicable for variables but not for objects, Whereas immutability is applicable for an object but not for variables.
- By declaring a reference variable as final, we won’t get any immutability nature, Even though the reference variable is final. We can perform any type of change in the corresponding Object. But we can’t perform reassignment for that variable.
- final ensures that the address of the object remains the same whereas the Immutable suggests that we can’t change the state of the object once created.
Why we should create immutable objects?
You Know What to Expect from an Immutable. Since the state of an immutable cannot change, we know what to expect from it. We know that the state of the object is valid throughout the object’s lifetime. Nowhere in the code can the state be changed to potentially introduce inconsistencies that may lead to runtime errors.
An Immutable Is a Gatekeeper for Valid State. If implemented correctly, an immutable object validates the state it is constructed with and only lets itself be instantiated if the state is valid. This means that no one can create an instance of an immutable in an invalid state. This goes back to the first reason: we can not only expect the immutable object to having the same state through its lifetime, but also a valid state. No more null checks or other validations strewed across the codebase. All those validations take place within the immutable object.
If we’re working with concurrent threads that access the same objects, it’s best if those objects are immutable. This way, we cannot introduce any bugs that arise from accidentally modifying the state of an object in one of the threads. Since the internal state of an immutable object remains constant in time, we can share it safely among multiple threads. We can also use it freely, and none of the objects referencing it will notice any difference, we can say that immutable objects are thread-safe and side-effects free.
Conclusion
Immutable objects don’t change their internal state in time, they are thread-safe and side-effects free. Because of those properties, immutable objects are also especially useful when dealing with multi-thread environments.
Every time we add a field to a class we should make it immutable (i.e. final) by default. If there is a reason to make it mutable, that’s fine, but unnecessary mutability increases the chance of introducing bugs and maintainability issues by unintentionally changing the state.
