Code refactoring - NULL check (Part 3)

Part 1
Part 2
Part 3
In my last two posts I wrote about “Null Object Pattern” in different scenarios. This post is related to this subject and we will discover how we can use this “pattern” when we are working with interfaces.
Let’s assume that we have the following interface and implementation of the interface:

public interface IFoo
{
  int A { get;set; }
  int B { get;set; }
  int C { get;set; }
}

public class Foo : IFoo
{
  public int A { get;set; }
  public int B { get;set; }
  public int C { get;set; }

}

In this case we would need a mechanism to implement a null object. We could create a static property to the Foo object that represents the null (default) value. This could be a solution but is not the best one.
Off topic: I really don’t like the NULL naming. I would prefer a name like “Default”.
What about creating a class that represents our null interface?
Creating a class that implement our interface that represent our null object will help us a lot when we need to check if the object represent the “null” object or an initialize object. Also, in this way we will not have our Foo class polluted with different fields/properties.

public class NullFoo : IFoo  
{
  private int _defaultA = 0;
  private int _defaultB = -1;
  private int _defaultC = -1000;
  
  public int A { get { return _defaultA } }
  public int B { get { return _defaultB } }
  public int C { get { return _defaultC } }
}

What we gain using this solution? We have a code that is clearer and easier to understand. On the other hand, we added complexity to our code. Also we still need to initialize the object with value and detect if an object represent the “null” object.
In conclusion even if this solution adds complexity to our code, the code will be easier to read and our intention is very clear to the reader.
Part 1
Part 2
Part 3