Code refactoring - NULL check (Part 2)

Part 1
Part 2
Part 3

In my last post we played a little with how we can check if an object is null or not. What I forget to mention in the post is the way how you can construct the object that can be null.
In the given case the constructor of the object was pretty complicated and you could not create the object without initialize a lot of items around him. As Tudor mention in a comment we could use the “Null Object Pattern”.
Let’s see how the code would look like if we could create an instance of the object. The “Null Object Pattern” is based on a neutral object that is considered the equivalent for NULL. This object contains all the default value of the properties that are exposed.
Using an object like this we don’t need to check if our item is null or not. We can directly access a property of it. During the lifetime of an application we should have only one instance of our object (Null Object) – the instance can be stored in a static field.
Using this solution we would end up with this:

public class SomeFoo
{
  public int A { get;set; }
  public string B { get;set; }
  public int C { get;set; }


  private static SomeFoo _nullInstance = new SomeFoo()
    {
      A = 0,
      B = null,
      C = -1
    } 
  
  public static SomeFoo NullInstance 
  {
    get
    {
      return _nullInstance;
    }
  }
}

public class Foo
{
  SomeFoo _some = SomeFoo.NullInstance;
  
  ...

  public int GetA()
  {
    return _some.A;
  }

  public string GetB()
  {
    return _some.B;
  }

  public int GetTotalX()
  {
    return _some.A + _some.C;
  }

}

This will work great if we don’t have cases when for the property “A” or “B” we need to return 0 and for a method that calculate “A”+”B” we need to return -1. But in the general case this solution works great.
In the next post we will see how we can implement this pattern when we are working with interfaces.
Part 1
Part 2
Part 3