Does Null Object Pattern occupy memory

I've been reading that the null object pattern will help you to avoid the null checks and null pointer exceptions making your code cleaner to understand.

I have never used it and I find it interesting. "null" won't occupy memory but if I start to replace my null checks with the creation of "default" objects, will this procedure have a negative impact in memory in long term?

ex:

Null Object Pattern

public void DoSomething()
{
  User user = this.GetUser(id);
  string strDisplayName = user.DisplayName;
}

public User GetUser(int id)
{
   User user = this.LoadUserFromDB(id);
   if(user ==  null)
      return User.CreateNull();
   return user;
}

So, as soon as I go out from the scope of the method, the object will be collected by the GC later. But what if I pass through a loop before going out from scope.

public void DoSomething()
{
  users = this.GetAllUsers();
  foreach(User user in users)
  {
     string strAddress = user.Address.StreetName;
     //continue tasks
  }
}

Meanwhile in other class

public Class User
{
   public Address Address
   {
      get
      {
         if(this.Address == null)
            this.Address = Address.CreateNull();
         return this.Address;
      }
   }
}

public class Address
{
   private string streetName;

   public virtual string StreetName
   {
      get { return this.streetName; }
      set { this.streetName = value; }
   }

   public static CreateNull()
   {
      return new NullAddress();
   }
}

public class NullAddress : Address
{
   public override string StreetName
   {
      get { retun String.Empty; }
   }
}

Null check

User user = this.GetUser(id);
string strDisplayName = String.Empty;
if(user != null)
{
   strDisplayName = user.DisplayName;
}

Just check if user is not null, so assign the property value. I won't create a "null" object

Thanks in advance.

Jon Skeet
people
quotationmark

Typically null objects aren't created on demand - instead, they're shared. They're typically immutable implementations of some other abstraction (with no-op methods or whatever is suitable) - so they can be shared very easily.

At that point, you've got a single object per null object type you're interested in, over the course of the whole application lifetime - and that's almost certainly insignificant.

people

See more on this question at Stackoverflow