Effective use of Nullable
Posted on May 22nd, 2009
In this post I will give a quick usage scenario for using Nullable<T> as well as the nice shortcut of the null coalescing operator ??.
I know when I first ran into some code with this ?? thing in it I was like what the heck is that. Well it is something that every developer should know about. So what does it do? If you are working with objects or value types that can be null you can use this to guarantee that you have a value.
Simple example of how this works:
string test = null; Console.WriteLine(test ?? "We had a null value");
What this will do is print “We had a null value” to the console. Now in .Net 2.0 they introduced Nullable<T> objects as well. The null coalescing operator can be used with these quite effectively as well.
Let’s look at a Date object and how we used to have to use it:
DateTime today = new DateTime();
if (today.Year == 1900)
{
today = DateTime.Now;
}
In the old days we would have old date times out there instead of a nice null value. So with .net 2.0 we can now do something like this.
DateTime? today = null;
if (!today.HasValue)
{
today = DateTime.Now;
}
Now that still looks like a lot of code. This is where the null coalescing operator comes into play. Take a look:
DateTime? today = null; today = today ?? DateTime.Now;
What this does is allows us to say, hey, if the today variable is null set it to DateTime.Now. It is clean and concise.
Now you may be also asking what the ? is after the DateTime variable. Well this is shorthand for the Nullable<T> object. You could also define the same code like this and it would mean the exact same thing. I just find the ? easier to read.
Nullable<DateTime> today = null; today = today ?? DateTime.Now;
As you can see not only are nullable objects handy but the null coalescing operator is even handier. So now you might ask can I use it on my own objects. The answer is YES you can use the ?? operator on anything that can be null. This gives this operator true versatility and should be in every developers playbook.
Using Predicate
Posted on May 14th, 2009
Unless you have been living under a rock or unable to use a newer version of .net since 1.1 you have probably run across the Predicate<T> object while using the List<T>. I know lots of people that use these Lists and there are other objects in the framework that use Predicate<t> as well. Another common one would be the Array object. The basic usage of the Predicate<T> object is to provide a delegate with a method that takes as a parameter the same data type of the object in your list. Then the List, Array, or some other object will essentially enumerate over your collection and test each object with this method. Thus the reason it returns a boolean.
What I’m going to show you here is a simple find process that will allow you to create a reusable delegate for use in the Predicate<T> processes using reflection.
First let’s get our pieces in place. Lets first see how to do it inline which is what most people use by default.
First lets define our person class we will use.
class Person
{
private string _firstName;
private string _lastName;
private int _age;
public Person(string firstName, string lastName, int age)
{
this._firstName = firstName;
this._lastName = lastName;
this._age = age;
}
public string FirstName
{
get { return this._firstName; }
set { this._firstName = value; }
}
public string LastName
{
get { return this._lastName; }
set { this._lastName = value; }
}
public int Age
{
get { return this._age; }
set { this._age = value; }
}
}
Next in our main app lets add some data.
List<Person> people = new List<Person>();
people.Add(new Person("John", "Smith", 35));
people.Add(new Person("Caitlin", "Smith", 13));
people.Add(new Person("Steve", "Long", 23));
people.Add(new Person("Justin", "Short", 45));
people.Add(new Person("Karigan", "Patterson", 16));
Now that we have data in our object we want to search. First I will show you the delegate method in-lined.
// Find one result
Person p = people.Find(delegate(Person p1) { if (p1.LastName == "Long") return true; else return false; });
Console.WriteLine("{0}, {1} - {2}", p.LastName, p.FirstName, p.Age);
As you can see we have created a delegate using the delegate keyword and we are passing in a object of the same datatype as our list as a parameter. Since we are doing a simple find operation we are looking for just 1 person with a last name of Long.
This statement is a little long but not too bad in the grand scheme of things. However what if you were writing an application where you had to do a lot of finds based on just 1 property. That in itself would be come very tedious and you would end up with a lot of repetitive code.
So now lets build a class that we can use to help us with this.
public class SimpleFind<T>
{
private string _property;
private object _valueToFind;
private PropertyInfo _p;
public SimpleFind(string property, object value)
{
this._property = property;
this._valueToFind = value;
this._p = typeof(T).GetProperty(this._property);
Protect.Against<nullReferenceException>(p == null, string.Format("Property {0} not found on type {1}", this._property, typeof(T).FullName));
}
public bool Find(T t)
{
try
{
if (this._p.GetValue(t, null).Equals(this._valueToFind))
{
return true;
}
else
{
return false;
}
}
catch
{
return false;
}
}
}
So let’s go over the class itself. First, you should notice that the class uses Generics in the class definition. The type you specify needs to match the type you use in your list. Next is the constructor. Since the delegate needs to take the type of object that matches your data type we need to pass in the information we need in the constructor. In this case since we are trying to find data based on a property value we specify the Property Name that we are going to search against and the Value we want to search for. Now the find method does all the real work though. In the find method you see we are getting the property via reflection and making sure that we actually have that property before we use it. The Protect object was discussed here. Other than that you will notice that the code pretty much matches what we did earlier.
Now to see the difference:
// Find one result
Person p = people.Find(new SimpleFind<Person>("LastName", "Long").Find);
Console.WriteLine("{0}, {1} - {2}", p.LastName, p.FirstName, p.Age);
As you can see it’s a bit shorter and highly reusable. So what if you wanted to find more than one record. The same class can be used again.
// Find one result
List<Person> p2 = people.FindAll(new SimpleFind<Person>("LastName", "Smith").Find);
Console.WriteLine(p2.Count.ToString());
Well that’s it. It’s a pretty straight forward process. However I find it very useful and easy to use and the nice thing about it is that since it’s an object you could re-use it with just a little bit of tweaking.
Enjoy.
*** UPDATE ***
After doing some more testing with this class I found that I needed to move the Property Info object up into the constructor to improve performance and reduce overhead. As well I moved the protect statement to the constructor as well as any error was causing the system to just return false and keep trying to process the find. It should stop. Last but not least the If condition in the find method was changed to just use the .Equals method.
Application Helpers: Protect your method calls
Posted on January 26th, 2009
First thing, refactor, refactor, refactor. Most ideas come from refactoring of your code. It’s amazing how much you do when you start refactoring things. The big benefit of course is less code. If you have a couple hundred thousand lines of code or even ten thousand lines of code, refactoring even a small thing can cut down your code base and improve readability. This article is geared towards refactoring.
In the course of working on multiple applications over the years you find you tend to do the same things over and over again. One of those things is constantly checking objects for null, data type compatibility, etc. How many times have you written the following lines of code.
if (object == null)
{
throw new ArgumentNullException();
}
or
if (object.GetType() == typeof(sometype))
The amount of code there justs adds up. Not only that but you probably have lots of null checks maybe even in the same method. So what if we wrote something like this instead:
Protect.IsNotNull(obj, "The object you are checking is null");
So if you had multiple objects going into an object you would have something like this:
Protect.IsNotNull(obj1, "Object 1 is null"); Protect.IsNotNull(obj2, "Object 2 is null");
Now since we are talking about refactoring what if we even refactor that code to make use of the newer features of the framework. Since the Protect methods throw an exception if the object is null in this case what if we wanted to expand it to allow for multiple checks. We could do something like this:
Protect.Against(obj1 == null, "Object 1 is null"); Protect.Against(String.IsNullOrEmpty(stringData), "The string is emtpy.");
As you can see we can now handle multiple things at the same time. So let’s look at what is under the Protect method.
public static class Protect
{
public static void Against(bool condition, string message) where T: Exception
{
if (condition)
throw new (T)Activator.CreateInstance(typeof(T), message);
}
}
As you can see not much but it makes your code easier to read and it adds a nice bit of conformity while reducing the total lines you need to maintain and worry about. The T parameter is the type of exception you want thrown based on your condition. As long as you have a boolean condition your good. Anything that evaluates to true will throw the exception. The message will be on the exception that is thrown. Based on this pattern we can also add things like Inheritance checks, Type checks, Enum, checks, etc. It’s really easy for it to morph into what you need as you need it. You can even extend it with delegates, Func<> methods, setup for linq style syntax, etc. the sky is the limit.
Here is what it would look like in use inside of a method:
public void DoSomething(List data, Dictionary other)
{
Protect.Against(data == null, "Data is null");
Protect.Against(other==null, "Other is null");
foreach (int i in data)
{
Console.WriteLine(other[i]);
}
}
Book Review: Release It!: Design and Deploy Production-Ready Software
Posted on January 17th, 2008
After reading on several blogs that this was a book worth getting I decided to get myself a copy. I will say that this is a great book and that it should be on every programmer’s bookshelf. This is right up there with Code Complete. If you have not already gotten a copy you should do so.
When it comes to technical books I like to only purchase books that I will continue to use over the years vs ones that are very targeted and will go out of date. Thus architectural books are a prime candidate for purchase. However knowing which to buy can be daunting. After all who wants to plop down $50 or more for a book that might only have 1 or 2 good chapters in it or is a rehash of books you already have. That’s where these reviews come in. I picked up this book based on reviews on other blogs and I was not disappointed. While the information in the book is presented by an obvious Java programmer it in no ways is tied to Java programming. It provides insight into several projects from the real world and things that they learned from them. As such it is more of a best practices book vs a code book. From Anti-Patterns to Patterns it walks you through various scenarios and things to watch out for when developing release ready software.
After reading the book myself I was able to make changes to the way I was coding my components to take advantage of these patterns. By making use of this pattern I was able to take a service interface layer and change it such that the application using it would not crash from this component as it had done in the past. I was able to accomplish this by using the circuit breaker pattern that he describes in his book. Basically what it does is very much what you would expect. Just like in a home if you plug too many items into your outlet and it overloads the circuit it throws the breaker so you don’t burn your house down. So in code what this does it allows you to implement your code such that if you run into problems it can shut down the interface or process without taking down your application with it. After all who wants to crash their application or website because an integration point is down or broken.
There are quite a few other patterns some of which I have already taken advantage of like the Fail Fast pattern. I can honestly say that after reading this book almost any developer should be able to walk away a better programmer and will most likely start to use some of the patterns presented in this book. I know I have.
All in all this was an excellent book and it was written very well and not all that expensive. If you would like to see a more in-depth review see this blog post, Ayende’s Blog.
This book should be on every developer’s bookshelf. Get it now. You can get it here: 
