There is a powerful and simple concept in programming that I think is really underused: Immutability

Basically, an object is immutable if its state doesn’t change once the object has been created. Consequently, a class is immutable if its instances are immutable.

There is one killer argument for using immutable objects: It dramatically simplifies concurrent programming. Think about it, why does writing proper multithreaded programming is a hard task? Because it is hard to synchronize threads accesses to resources (objects or others OS things). Why it is hard to synchronize these accesses? Because it is hard to guarantee that there won’t be race conditions between the multiple write accesses and read accesses done by multiple threads on multiple objects. What if there are no more write accesses? In other words, what if the state of the objects threads are accessing, doesn’t change? There is no more need for synchronization!

Of course I simplify here so let's dig a bit.

A famous immutable class

There is one famous immutable class: System.String. When you think that you are modifying a string, you actually create a new string object. Often, we forget about it and we would like to write …

string str = "foofoo";

str.Replace("foo", "FOO");

…where we need to write instead:

str = str.Replace("foo", "FOO");

Of course, doing so comes at the cost of creating multiple string objects in memory when doing some intensive string computation. In this case you need to use the System.Text.StringBuilder class that provides a safe way to work with mutable string.

Actually, string objects are not that immutable and as far as I know there are at least 2 ways to break string immutability. With pointers as shown by this code example and with some advanced System.Reflection usage.

So why .NET engineers decided that string should be immutable? Because programmers will never get a race conditions because of a corrupted string. Also because string are well adapted to be key in hashtables (i.e Sytem.Collections.generic.Dictionary<K,V>). Hashtables are almost a magic way to enhance dramatically performance of your code. (I said magic because under the hood hashtables rely on prime numbers properties and prime numbers are magic!). The objects on which the hash values are computed must be immutable to make sure that the hash values will be constant in time. Indeed, hash value is computed from the state of the object (or eventually a sub-state of the object, then only this sub-state must be immutable).

Another cool thing about string immutability is that even though System.String is a class, string objects get compared with equivalence, as a value type. This is possible because we can consider that the identity of an immutable object is its state. For example:

string str1 = "foofoo";

string strFoo = "foo";

string str2 = strFoo + strFoo;

// Even thought str1 and str2 reference 2 different objects

// the following assertion is true.

Debug.Assert(str1 == str2);

Purity vs. Side-effect

 
So we now know at least 3 great benefits of immutable objects:

• They simplify multithreaded programming.
• They can be used as hashtables key.
• They simplify state comparison.

We can now be more general and say that the primary benefit of immutable types come from the fact that they eliminate side-effects. I couldn’t say it better than Wes Dyer so I quote him:

We all know that generally it is not a good idea to use global variables.  This is basically the extreme of exposing side-effects (the global scope). Many of the programmers who don't use global variables don't realize that the same principles apply to fields, properties, parameters, and variables on a more limited scale: don't mutate them unless you have a good reason.(…)

One way to increase the reliability of a unit is to eliminate the side-effects. This makes composing and integrating units together much easier and more robust.  Since they are side-effect free, they always work the same no matter the environment.  This is called referential transparency.

Immutable classes in C#

C# supports immutability thanks to 2 keywords: const and readonly. They are used by the C# compiler to ensure that the state of a field won’t be changed once an object is created. Why 2 keywords? Because the readonly keyword allows state modification within constructor(s) while the const keyword doesn’t. For example:

class Article {
   Article(string name,int price) {
      m_Name = name; // <- Compilation error
      m_Price = price;
   }
   const string m_Name = "Ballon";
   readonly int m_Price;
}

At this point you might wonder what if my object references another object through a read-only fields? Does the state of the referenced object can change? The answer is yes, this is the classical shallow vs. deep paradigm. Eric Lippert from the C# team has a nice post describing these different kinds of immutability. Actually Eric did a great range of posts on how to code efficient immutable collections, which might sound paradox since collections are known as super-mutable objects. Check its posts done since november 2007! Also Eric wrote:

Immutable data structures are the way of the future in C#.

So stay tuned!

Immutable closures in C#2

The functional coding-style is more adapted to immutable state than the imperative one. Wesner Moise often praises on its blog the use of functional closures as a mean to achieve immutability. For example, here is a simple program that defines immutable objects. These objects are affine transformer that take an integer x and that compute a*x+b. Thus, the state of our immutable affine transformer object are the a and b parameters. Here is the code:

using System.Diagnostics;
class Program {
   delegate int DelegateType(int x);
   static DelegateType MakeAffine(int a, int b) {
      return delegate(int x) { return a * x + b; };
   }
   static void Main() {
      DelegateType affine1 = MakeAffine(2, 1);
      DelegateType affine2 = MakeAffine(3, 4);
      Debug.Assert(affine1(5) == 11);  // 2*5+1 == 11
      Debug.Assert(affine2(6) == 22);  // 3*6+4 == 22
   }
}

If you are not acquainted with closure this code might surprise you. Behind your back, the C# compiler has created an immutable class to represent these affine transformer objects! I wrote an article about closure in C# that explains all this.

Immutable anonymous types in C#3 and VB9

C#3 comes with the interesting anonymous types feature. Anonymous types built by the C#3 compiler are immutable, all fields are private and all properties are read-only (it is always instructive to check by yourself with Reflector).

var affine = new { A = 3, B = 4 };

affine.A = 3; // <- Compilation error

On this post, Tim Ng from the VB.NET team, wrote:

The motivating factor for driving the immutable anonymous types was because the LINQ APIs used hash tables internally and returning projections of anonymous types that could be modified was a dangerous situation.

Interestingly enough, the VB team decided that their anonymous types wouldn’t be immutable by default, which means that you can write such things:

Dim affine = New With {.A = 3, .B = 4}

affine.A = 5

However, the VB team added the possibility to specify that a certain property would be read-only thanks to the Key keyword:

Dim affine = New With {Key .A = 3, .B = 4}

affine.A = 5    ‘ <- Compilation error

About the motivation behind having mutable anonymous types in VB Tim Ng wrote:

…but for Visual Basic, we decided that because we have the ability to late bind on top of anonymous types, making them immutable is unexpected.

Immutable support in NDepend and CQL

As we saw, immutability is a feature that can be enforced at compile-time. In other words it can be enforced by static analysis tools. Thus, the Code Query Language (CQL) that comes with the static analysis tool NDepend has an IsImmutable condition that applies on types. To know which types of your code base are immutable it is as easy as writing this CQL query:

SELECT TYPES WHERE IsImmutable

To constraint a particular type MyNamespace.Foo to be immutable you can write this CQL constraint:

WARN IF Count != 1 IN

SELECT TYPES WHERE IsImmutable AND FullNameIs "MyNamespace.Foo"

To constraint a range of types used by the class MyNamespace.Foo to be immutable:

WARN IF Count > 0 IN

SELECT TYPES WHERE IsUsedBy "MyNamespace.Foo" AND !IsImmutable

To constraint a range of types declared in the namespace MyNamespace to be immutable:

WARN IF Count > 0 IN

SELECT TYPES FROM NAMESPACES "MyNamespace " WHERE !IsImmutable

To constraint a range of types tagged with an attribute MyNamespace.MyImmutableAttribute to be immutable:

WARN IF Count > 0 IN

SELECT TYPES WHERE IsDirectlyUsing "MyNamespace.MyImmutableAttribute" AND !IsImmutable

In a near future we will add the condition HasAttribute and we will be able to write more properly:

WARN IF Count > 0 IN

SELECT TYPES WHERE HasAttribute "MyNamespace.MyImmutableAttribute" AND !IsImmutable

There is something about immutability that we didn’t mention: all primitive value types (int, double, decimal, byte, bool…) are immutable. More generally it is recommended to make all structures immutable. It makes them suited for hash value computation, suited for equivalence comparison, and creating more structure instances won’t overwhelm the GC. To guarantee that all your structures are immutable just write this constraint:

WARN IF Count > 0 IN

SELECT TYPES WHERE IsStructure AND !IsImmutable

 
So, what’s behind the IsImmutable CQL condition? Here are the rules that NDepend uses to decide if a type is immutable or not:

• A type with at least one non-private instance field is considered as mutable (because such a field can be eventually modified outside of the type).
• A type that has a method that is not a constructor and that assign an instance field is considered as mutable.
• A class that derives directly or indirectly from a mutable type is considered as mutable.
• Enumeration, static type, type defined in tier assemblies and delegate classes are never considered as immutable. Although these types might match the definition of immutability, considering them as immutable would disturb developers while they care for their own immutable types.
• Particularly, classes that derive directly or indirectly from a class defined in a tier assembly that is not the System.Object class, is never considered as immutable.

Beside the IsImmutable condition on types, we also added 2 conditions on methods: ChangesObjectState and ChangesTypeState. As the name suggest, ChangesObjectState match methods that are assigning an instance field of its class and the ChangesTypeState match methods that are assigning a static field of its class.

The condition ChangesObjectState matches constructors. A static method or a class constructor can also be matched, for example, if it modifies the state of an instance passed by reference. Notice also that an instance method of a type T that modifies an instance of T that is not the one referenced by the this reference is also matched.

The condition ChangesTypeState matches class constructor, constructors, instance methods and static methods.

These 2 conditions can be used to see at a glance which methods can change the state of your program, in other words, which methods are mutable or non-const, or better said, which methods provoke side-effects. And as Wes Dier wrote: One way to increase the reliability of a unit is to eliminate the side-effects.

SELECT METHODS WHERE ChangesObjectState AND !IsConstructor AND !IsClassConstructor

SELECT METHODS WHERE ChangesTypeState AND !IsConstructor AND !IsClassConstructor

ChangesObjectState can be also used as the good old C++ keyword const that make sure that a method won’t corrupt the object state:

WARN IF Count != 1 IN SELECT METHODS

WHERE ChangesObjectState AND FullNameIs "MyNamespace.Foo.MyConstMethod()"