Geeks With Blogs
Mike Nichols - SonOfNun Technology If I were the captain on a big steamboat...

Let's say I have a class Person with your typical field/properties FirstName, LastName, blah, blah... Then let's say I decide to implement the Null Object Pattern. Why I decide this isn't important right now, but I know that I am just going to initialize all my fields to default setttings (string.Empty for FirstName,LastName, etc..) in the constructor. Like so:

    public class NullPerson : Person, INull

    {

        public NullPerson() : base(string.Empty,string.Empty,string.Empty,null)

        {

        }

 

 

    }

Now, notice I have a marker interface called INull. In my code later on I might have something like :

if( person==null || person is INull )
  // do something

This kind of code flags me to consider using Specification to encapsulate these kinds of checks. So in a project that is Common to all in my solution, I write this simple little object:

    public class NonNullSpecification<T> where T : class

    {

        public bool IsSatisfiedBy(T item)

        {

            return item != null && !(item is INull);

        }

    }

I'm include the T:class in my where clause to prevent the use of this spec on ValueType derivatives.

This is implementing a variation on a slick generic Specification that Jean-Paul Boodhoo demonstrated and is implementing the pattern that is discussed deeper in Eric Evans' Domain Driven Design book.

    public interface ISpecification<T>

    {

        bool IsSatisfiedBy(T item);

    }

Now to use in my code I can just use this to check for nulls in a consistent way across my app

            return new NonNullObjectSpecification<Person>().IsSatisfiedBy(e.Person);

I admit this is an edge-case example...doing this may not be justified. But I love encapsulating these tiny rules that span my application so that if they change for whatever reason, I can go to one place to change them. I know checking for null isn't prone to change, but think of how many times you had to go finding code that implemented a rule and make those changes manually (ReSharper would help alot, too I know). The point is, when I see myself doing checks on things more than once, I try to ask whether this is a Specification that i haven't identified yet and see if I can wrap those rules into a consistent interface.

Posted on Thursday, August 24, 2006 7:17 AM OOP, Patterns, Architecture , C# , Domain Driven Design (DDD) | Back to top


Comments on this post: When I see this more than once...

# re: When I see this more than once...
Requesting Gravatar...
Good point on use of specifications, but I have to argue against your null object example: if you're still checking to see if something is INull you haven't really gained anything over checking to see if it == null. The point of NullObjects is that you call them as though you were calling any instance without having to check, and they then just silently don't do anything (or do whatever should happen in the case of them being null). I realize that this isn't the main thrust of your entry, but then a truer example might also better explain why someone would want to use specifications in the first place. Perhaps in keeping with your Person name example, you could imagine having to gather up all the French names vs all the Lithuanian names vs all the Biblical names vs all the hyphenated names vs all the names ending in "son".
Left by Larry Delvino on Apr 30, 2007 6:09 PM

Your comment:
 (will show your gravatar)


Copyright © Mike Nichols | Powered by: GeeksWithBlogs.net