Looking for new “brainfood” on programming topics on the internet I came across a really interesting article about immutable types in C# from Joe Duffy who happens to be the lead developer and architect for Parallel Extensions to .NET. If an object of a given types is immutable that means that the state of the object will never change after being constructed. Joe Duffy explains and shows by example how immutable types could be approached in .NET
by following the five rules below:
- Immutable types must have only init only fields.
- Immutable types must only contain fields of immutable types.
- Immutable types should only subclass other immutable types.
- Mutable types should not subclass immutable types.
- Immutable types must not leak the ‘this’ reference during construction.
More information about immutable types in C# and the five rules above can be found in the following article:
http://www.bluebytesoftware.com/blog/2007/11/11/ImmutableTypesForC.aspx
I miss an explanation what immutable objects are used for.
I know reasons in multi-threading (immutable objects are per se thread safe) and any variation of observer pattern (observer can not manipulate observee).
Other situations where immutable objects come in handy?
Cheers,
Urs
Hello Urs,
Your right the article is not complete. Let me add some more details here:
As already describe an immutable object is an object whose externally visible state cannot change after instantiation. Java theory according to http://www.ibm.com/developerworks/java/library/j-jtp02183.html summarizes in my point of view really well the benefit of immutable objects such as:
1. Freedom to cache: Because there is no danger of immutable objects changing their value, you can freely cache references to them and be confident that the reference will refer to the same value later. Similarly, because their properties cannot change, you can cache their fields and the results of their methods. […]
2. Inherent thread safety: As previously mentioned by you urs. […] As long as immutable objects are constructed properly (which means not letting the object reference escape from the constructor), they are exempt from the requirement to synchronize access, becuase their state cannot be changed and therefore cannot have write-write or read-write conflicts. […]
3. Safe in the presence of ill-behaved code: Methods that take objects as arguments should not mutate the state of those objects, unless they are explicitly documented to do so or are effectively assuming ownership of that object. When we pass an object to an ordinary method, we generally don’t expect that the object will come back changed. However, with mutable objects, this is simply an act of faith. […]
4. Good keys: Immutable objects are considered good keys for HashMaps or HashSets
See the full article on: http://www.ibm.com/developerworks/java/library/j-jtp02183.html