MyType.Empty


Many times it is common to have a class that has a very common object instance that is used at a lot of places. Like the empty string for the string class. In such cases its very convenient to keep such a pre-constructed object around for easy reference.


This saves memory as the same reference can be used all-over. Even for strings where the same interned string is returned, it saves the time of trying to construct that object. It also saves the work of trying to figure out how to make that common instance.


Examples of this pattern abound in the .NET framework. The most common being String.Empty which represents an empty “” string. The others are IntPtr.Zero, Color.Red (same as new Color(255,0,0);) and many more…


This pattern is typically implemented as follows

public class MyClass

{

int val;

public int Val

{

get { return val; }

set { val = value; }

}

public MyClass(int val)

{

this.val = val;

}

public MyClass() {}

public static readonly MyClass Empty = new MyClass(0);

}


If you compile this code with Code Analysis (FxCop) enabled you’ll get a security warning (CA2104) on the last line. The reason is that, since the class is not immutable one can write the following code

MyClass.Empty.Val = 5;

MyClass mc = MyClass.Empty;// get modified value

Console.WriteLine(mc.Val); // prints 5 and NOT 0


The first line changes the value for the Empty instance and all subsequent accesses get the changed value. This can be due to a bug or someone can easily use this as an attack to break a system. However if you remove the set accessor for the MyClass class then this threat goes away. String uses this pattern because strings are immutable.


So the bottom line is that use this pattern only on immutable types.


On a related note Color.Red or other such colors do not return a pre-constructed color. It creates and returns a new color and just provides an easy way to create a new standard color.

Comments (5)

  1. Roger Bucks says:

    When you say that you remove the get accessor, do you mean the set accessor?

    I presume the line you are trying to make illegal is MyClass.Empty.Val = 5?

  2. Kalpesh says:

    I suppose, Mutator is what you meant. Right?

  3. MZ says:

    This is yet another usefulness of immutable classes – the problem is that immutable classes are so hard to work with.  When I first found your blog (an old post) I made a lengthier comment on the subject:

    http://blogs.msdn.com/abhinaba/archive/2005/09/17/470358.aspx#772301

    Basically: immutables are a headache in DotNet languages, and don’t look to be getting it easier.  I’ve been thinking it over and a codegen may be the way around it:  Basically, you design a constructor for the class that corresponds to every public field.  Then you codegen a CopyWithX instance method that creates a copy of your immutable class with the property X being different, with one X for each public property.  The problem is that the copy constructor and the suite of CopyWithX methods would have to be regenerated for each change in the public properties of the class.

  4. abhinaba says:

    Roger, I did slip in a typo there. I did mean a set accessor.

    MZ I do rememer you comment. Some of us discusses this as well. However, doesn’t look like there is an easy solution to this either.

  5. Shahar says:

    The issue with Color is somewhat different. Since Color is a structure and it would have been copied anyway, it doesn’t make sense (in this case – since the initialization is so cheap) to actually have precreated instances – it saves you nothing.