Do we really care ? We should but we don’t. I mean sometimes people just doesn’t think in terms of mutability or immutability and after the design it becomes headache to change the API (probably because you have already distributed code and now you can’t simply change the stuff !) and it remains there forever.
So, What do you mean by Mutable and Immutable object ?
You can call any object a
Mutable Object - if state of object can be changed/modified after its creation.
Immutable Object – If state of object could not be changed/modified after its creation.
Watch out for: Immutable object holding a reference of mutable objects.
e.g. Class Foo is immutable and holding a reference of Class Bar, which is mutable.
What’s the issue with mutability ?
Take it java collection API for instance, you have an Object holding a List of some Objects and you would like to provide a getter method for List, now you can’t just return a List reference by getter method because List implementations are mutable (e.g. java.util.ArrayList) and due to this fact anybody can change the List contents, which is not acceptable. Even returning the Iterator could not help as it got remove() method using which anyone could remove the elements. You can use google collections or utility methods from Collections class to return the Immutable versions but it still implements List Interface so you have to check for stray immutable collections before executing the contract (say add() method ) ! This is because all collection types are mutable.
Take another example – Lets say you have Customer class having reference to CreditCard class, and you have to put getter method for CreditCard (for validations and all ) but CreditCard designed as mutable object. So you can’t simply return the reference of original CreditCard object but you have to make a copy of the CreditCard object and return the same so even somebody change the CreditCard your original CreditCard object should not affect. but in this scenario if getter method called hundred times then you end up creating hundred objects (of course useless objects) just because CreditCard was designed mutable.
There are number of scenarios where people actually required Immutable objects but designed as a mutable and later these objects becomes painful to handle. I have seen people asking why we need immutability and I think we should ask why mutability and does it really what we need, if we have justifiable answers then go with mutability else stick to immutability.
Immutability … what we gain ?
Avoids unnecessary object creation : When we design the immutable object, we are quite sure about its consistency and we can reuse it again wherever required. e.g. String in java is immutable, so java doesn’t need to make new String objects every time (Unless you say so by calling the constructor of String) when program needs it.
Data Consistency: As state of so we are quite sure whatever is object state is same as when object was created.
Thread safety: Immutability comes with thread safety.
Makes code more reliable by avoiding possible inconsistency in object states.
These are some benefits with immutability that matters in day to day programming but there could be various benefits also depending upon the various scenarios, so thumb rule is ask yourself – Do you really need this object mutable ? if you can not justify,stick to immutability.
