I know that immutable objects always have the same state, the state in which they are actually created. Their invariants are establised by the constructor and since their state does not change after construction , those invariants always hold good and this is why they are safe to publish in a multi threaded environment. This is all fine but since we live in a dynamic world , where the state of program changes continuously , what benefits do such objects give us if we construct the state of our program through immutable objects?
-
Here is another post that may have the answer to your question: http://stackoverflow.com/questions/214714/mutable-vs-immutable-objects – Hunter McMillen Jul 02 '12 at 12:57
-
Immutable objects are like Facts. Facts don't change but you can always 'make' new ones. – Stefan Jul 02 '12 at 13:27
4 Answers
"what benefits do such objects give us" you already answered that.
Regarding the "dynamic" part of your question, if you need to "change" an immutable object, you can create a new one from the old one:
Immutable oldObj = new Immutable(...);
Immutable newObj = new Immutable(oldObj.property1, "a new value for property 2");
If you find that you keep doing that repeatedly, then maybe you need to make the object mutable and add the relevant tread-safety features that are needed to be able to use that object in a concurrent environment.

- 321,522
- 82
- 660
- 783
Immutable objects allow you to cleanly communicate changes of state to different threads.
It is a good practice to use immutable objects to represent messages exchanged between threads. Once such message is sent, its payload can not be altered, which prevents many concurrency related bugs. If a thread needs to communicate some further changes, it just sends next messages.

- 6,969
- 3
- 37
- 53
Immutable objects
are very helpful when you need some static object whose state never changes .Greatest advantage are immutability , object semantics and smart pointers renders object ownership a moot point. Implicitly this also means deterministic behaviour in the presence of concurrency.
Java has already defined some Immutable classes like String
Integer
.
Other benefit is they always have "failure atomicity" (a term used by Joshua Bloch) : if an immutable object throws an exception, it's never left in an undesirable or indeterminate state .
Let say if you have a global cache of static objects like country codes , here you can apply Immutability
.
-
Not only do immutable objects themselves have failure atomicity, but such atomicity often extends to mutable holders of such objects. If I `Fnord` is an immutable class, and an object has a field `foo` of that class type, a statement like `foo = foo.WithWizzleAndWozzle(5,3);` [which should effectively change the value of `foo.Wizzle` to 5 and `foo.Wozzle` to 3] will either changing both values or neither. There's no way it can change one without changing the other. – supercat Jul 02 '12 at 17:51
Immutable objects are really useful in cases like this, with a String object:
public class A {
private volatile String currentName = "The First Name";
public String getCurrentName() {
// Fast: no synching or blocking! Can be called billions of times by
// billions of threads with no trouble.
// (Does need to be read from memory always because it's volatile.)
return currentName;
}
public whatever someMethod() {
... code ...
// Simple assignment in this case. Could involve synchronization
// and lots of calculations, but it's called a lot less than
// getCurrentName().
currentName = newName;
... code ...
}
}
public class B {
... in some method ...
A objA = something;
// Gets "name" fast despite a billion other threads doing the same thing.
String name = objA.getCurrentName();
// From this point on, String referenced by "name" won't change
// regardless of how many times A.currentName changes.
... code with frequent references to objA
}
This allows complex data (or even simple data, this case) that must be consistent (if not precisely up-to-date) to be updated and delivered to anybody who wants it very quickly and in a thread-safe manner. The data delivered will soon become outdated, perhaps, but it will keep its value during the calling method and remain consistent.

- 3,108
- 16
- 18