Cached empty collections

Question

I often find myself in need to create empty collections. One of those days several years ago, I wrote something like the following to address that:

public static class Array<T>
{
    // As a static field, it gets created only once for every type.
    public static readonly T[] Empty = new T[0];
}

I didn't know about Enumerable<T>.Empty(); maybe it didn't exist back then. Although I know now, I still use this one. Maybe because I know the actual implemention or maybe I just overly used to it.

// All these variables share the same array's reference.
string[]            empty1 = Array<string>.Empty;
IEnumerable         empty2 = Array<string>.Empty;
IEnumerable<string> empty3 = Array<string>.Empty;

Although switching to Enumerable<T>.Empty() is probably the best since it's now the de facto way to create an empty collection but I still have my doubts.

I wrote this firstly because it does caching of its empty array references but MSDN says Enumerable<T>.Empty() does cache the empty results, too.

So the only advantage of using Array<T> I can think of now, is that it returns an array:
There are still many functions that need an array of values instead of IEnumerable<T>, IList<T> or IReadOnlyList<T>. And array implements all of these so it can be used anywhere.

---

What do you think about this class?
Can you see any other advantages/disadvantages of it over Enumerable<T>.Empty()?

And about implementation:
Do you think making the caching using a static field would cause any problem?

Answer 1

Your solution is absolutely correct and practical.

In fact Enumerable.Empty<T> also returns empty array under the hood, just slightly in a different way (they have a separate instance holder class that is lazily initialized).

Answer 2

I think it entirely depends on context.

Enumerable<T>.Empty() was clearly introduced for syntactic sugar in Linq. I see no reason to use it over a plain old new-statement.

The wider question about caching and efficiency depends on the code-base. Calling a list "Empty" explicitly states intent and could help readability, but if you later go on to add items to that collection in any way, it actually makes the code more confusing.

As far as any problems with the "cached, static" field go, the obvious problem is that if someone was foolish enough to place a lock on that static list, it could cause all manner of issues in your application as it'd act as a point of coupling.

I'd always avoid using shared static references if you don't need them for any specific reason, especially if it's a perceived performance problem that has never been encountered. You can't really get much safer than an instance variable with a new empty list in it.

Conversely, if you're really up against the wire with performance, there may be a good reason here, but you'd probably find that if you're micro-optimising list initialisation, there's a better higher level optimisation to be made.

Answer 3

this kind of implementation of static default type for a given type is a well known pattern called "Nullobject Pattern" (more info here : http://en.wikipedia.org/wiki/Null_Object_pattern).

I've used this to avoid comparing to null and instead return objects of the given type that have default values.

example:

public class Person
{
  public string Name {get;set;}
  public uint Age {get;set;}


  //chaining constructor pattern
  public Person : this(string.empty,default(uint))
  {
  }
  public Person(string name,uint age)
  {
     Name=name;
     Age=age;
  }

  //null object pattern
  private static readonly Person _defaultPerson = new Person();

  public static Person Null 
  {
    return _defaultPerson;
  }
}