Skip to main content

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

Comments

Popular posts from this blog

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 …

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&#…

Fundamental Books of a Software Engineer (version 2018)

More then six years ago I wrote a blog post about fundamental books that any software engineer (developer) should read. Now it is an excellent time to update this list with new entries.

There are 5 different categories of books, that represent the recommended path. For example, you start with Coding books, after that, you read books about Programming, Design and so on.
There are some books about C++ that I recommend not because you shall know C++, only because the concepts that you can learn from it.

Coding

Writing solid codeCode completeProgramming Pearls, more programming pearls(recommended)[NEW] Introduction to Algorithms

Programming

Refactoring (M. Fowler)Pragmatic ProgrammerClean code[NEW] Software Engineering: A Practitioner's Approach[NEW] The Mythical Man-Month[NEW] The Art of Computer Programming

Design

Applying UML and Patterns (GRASP patterns)C++ coding standards (Sutter, Alexandrescu)The C++ programming language (Stroustrup, Part IV)Object-oriented programming (Peter Coad)P…