Skip to main content

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

Comments

  1. I would call this 'Empty object pattern'. It is a lot more useful for languages where you can have objects on the stack (C++), making the default value (filled in by calling the default constructor) the "Empty Object". Checks, in this case, are natural; you check against an empty object; having such an object as a static member of your class is also easy to implement.
    Using it as a replacement for null tries to avoid the precise programming mistake that the null initialization tries to signal: the fact that a variable is uninitialized. This pattern, having a valid object where we would otherwise have a null pointer exception (or a Segmentation fault) may obscure errors that would have been triggered by the exceptional conditions of having a null object.

    Suggestion: please remove all the captchas, they discourage dialogue :)

    ReplyDelete
    Replies
    1. captchas - For a limited period of time I removed them but I had 10-15 spam messages that were not removed by the spam filter of Google

      Delete
    2. I think that this 'null object pattern' is useful in those cases where null is an expected value and has a certain meaning - instead of having to add comments on what null means for a certain method, sometimes we can replace it with a derived class with an appropriate name (like CustomerNotSpecified), embed in it's methods the specific logic and make the code more elegant in this way. This has nothing to do with avoiding null ref exceptions or input validation, when null would be an invalid argument.

      Delete
    3. I understand the purpose of an 'empty object' but I wouldn't use the 'null' name and I wouldn't name it 'a pattern' (unless we're ready to call 'if' a binary conditional operation selection pattern and a 'switch' a multiple conditional operation selection pattern). That would be rather silly.
      Or not.

      Delete

Post a Comment

Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…