MrKWatkins

Fluent Argument Validation Part 2 - The Approach

As covered in part one I have decided to create a fluent library for validating arguments as I wasn't happy with ones currently available. But what exactly do I want?

• To explicitly state that we are validating arguments
• To validate that the user has not passed in a null or empty parameter name
• To specify the argument and parameter name once and then be able to chain a series of validations
• To not have to specify when to validate (e.g. with a .Check() or .Validate() method)
• To stop the user chaining non-sensical validations together, where possible

Which gives a syntax something like this:

public static void SomeMethod(string stringValue, int intValue)
{
    Validate.Argument(stringValue, "stringValue")
        .IsNotNull()
        .IsNotEmpty();
        
    Validate.Argument(intValue, "intValue")
        .IsPositive()
        .IsLessThanOrEqualTo(5);

Why have I created a class called Validate with a property called Argument rather than a class called ValidateArgument? This is so I can expand the library to validate other things apart from arguments, all from the same starting point. For example I could expand it to do things like:

public static void SomeOtherMethod<TEnum>(TEnum enumValue, string directory) where TEnum : struct
{
    Validate.TypeParameter(typeof(TEnum), "TEnum")
        .IsEnum();
        
    Validate.Directory(directory)
        .Exists()
        .IsEmpty();

So, how am I going to actually code this thing? Well if I'm going to chain these validations together then I will need to store the argument and parameter name somewhere. There are a two obvious ways to do this:

1. Store them in a field somewhere. This would need to be a thread safe; threading issues are hard enough to debug at the best of times without argument validation giving you apparently false exceptions...
2. Create an object to hold them in. However the methods in the chain will need to change depending on depth; we don't want to allow two calls to IsNotNull() in a row for example. Therefore we are either going to need to create a new object when the methods in the chain change or create one object that implements multiple interfaces explicitly and then cast it to a different interface when then methods in the chain change. And should our objects be structs or classes?

Which way is best? Are any methods intrinsically worse for some reason? Performance is a good reason. Whilst I'm a firm believer that you should get you application working and performance enhance after (slow code is better than no code!) I also think prototyping is a good idea. If we can do a simple test at this stage then we might well find out that one approach is fundamentally slower than the others.

So I've knocked together a simple application to test each method and see which is quickest; feel free to play with the source code. It measures how long it takes to validate a string argument is not not null and not empty 25,000,000 times, compared against two not so fluent methods. On my PC the results are: (times in seconds)

So it looks like the single class approach wins. A few things to note though:

• This test is for two chained calls; I suspect we might find a using structs is faster for a single call. But then one of the points of this library is that you can chain methods... Besides I seem to spend half my life validating strings for not null and empty so I reckon my code will be using chains of two or more items quite a lot...
• Not as fluent, separate methods is fairly close to the single class approach. This might be because it has to validate that the parameter name is not null or empty twice whereas the single class approach only has to do it once.
• Although creating multiple structs is quicker than multiple classes (as you'd expect; in the current .NET implementation local structs are allocated on the stack so there is no need to garbage collect them and perform all the tracking that goes with that) creating a single struct isn't. This is due to boxing. Interface methods are defined as being virtual but structs simply don't have it in them to handle that (they're missing a vtable to lookup the virtual methods) so they get boxed, giving us the performance hit.
• The CLR team have clearly optimised the crap out of ThreadStatic fields given that they're 20 times faster than using named data slots.

So I have an approach. In the next post I'll start to look at implementing it.

Fluent Argument Validation Part 1 - The Competition

I like fluent interfaces. And I'm very pedantic about validating arguments. So I went looking for a fluent interface for validating arguments. And I found a few, but none were quite what I'm looking for. So yup, I decide to write my own.

Before explaining how I did that though I would like to mention a couple of those and explain why they are not what I'm after; hopefully that will help to why I felt the need to write my own.

Paint.NET

An excellent article on the Paint.NET blog gives details of one approach. Whilst taking care to optimise for the non-exceptional path (no objects are created unless validation fails) it didn't feel fluent enough for me. An example of the interface given is:

public static void Copy<T>(T[] dst, long dstOffset, T[] src, long srcOffset, long length)
{
    Validate.Begin()
        .IsNotNull(dst, "dst")
        .IsNotNull(src, "src")
        .Check()
        .IsPositive(length)
        .IsIndexInRange(dst, dstOffset, "dstOffset")
        .IsIndexInRange(dst, dstOffset + length, "dstOffset + length")
        .IsIndexInRange(src, srcOffset, "srcOffset")
        .IsIndexInRange(src, srcOffset + length, "srcOffset + length")
        .Check();

For me a fluent interface should allow you to specify something, and then let you chain a sequence of operations on that something. jQuery is the an excellent example of a good fluent interface; you specify an element and then perform a chain of actions on that element. For argument validation I would expect us to specify an argument and then chain a sequence of validations on that element. Which is why I don't feel this interface is fluent enough for me. It does not specify an argument at the start, but rather it specifies the arguments each time. Consider the following example of the above style:

public void DoSomething(int? argument)
{
    // Check argument isn't null and is between 0 and 100.
    Validate.Begin()
        .IsNotNull(argument, "argument")
        .IsGreaterThanOrEqualTo(argument, "argument", 0)
        .IsLessThanOrEqualTo(argument, "argument", 100)
        .Check();

Doesn't seem much point to me in chaining the methods if we keep having to specify the argument and parameter name each time.

Of course there are valid reasons for this; if we don't specify the argument and parameter name each time then we are going to have to store them somewhere and that means a tiny performance hit; you're gonna need to set a field or create and object or do something to store that information. For an application like Paint.NET that needs every ounce of performance that could well be a problem.

For my interface I'm willing to take a tiny performance hit to get the interface I want. If I have to create a short lived object or set a field then I'm not too fussed about that to be honest. I find there are a lot of people who would moan about such things. Sometimes for good reason. But more often they'll complain that I should use a byte instead of an int whilst at the same time think that boxing is a sport and an expression tree is a plant that smiles. If I've optimised every other area of my application and actually need to get a bit of extra performance then I'll be a happy man. And I'll just drop the argument check...

Roger Alsing's Argument Validation Framework

Roger Alsing has a good approach. Much more fluent; we only specify the argument once:

public static string ValidationFunc(int a, string b, DateTime c)
{
    a.Require("a")
        .IsGreaterThan(10);

    b.Require("b")
        .NotNull()
        .NotEmpty()
        .LongerThan(2)
        .StartsWith("Ro");

I have two main problems with this approach:

1. Making Require an extension method on object; what if my object isn't an argument? What if it's a field or a local object? Admittedly it also has an overload without the parameter name (i.e. a.Require()) so it can be used as a general validation method. But I would prefer to be explicit about the fact that we're validating an argument.
2. There doesn't seem to be anything to prevent you doing something silly. And programmers often do silly things; we should try to stop them wherever possible.. For example, the following are allowed:
   
   b.Require("b").NotNull().NotNull().NotNull().NotNull().NotNull().NotNull();

a.Require("a").IsGreaterThan(4).Require("b").NotNull();

.NET Junkie

.NET Junkie outlines a similar approach. The article talks about the relationship to Spec# which gives some more info on why the interface is created like it is. I just want to validate my arguments in a nice fluent way which are my pre-conditions. As for post-conditions my method code should be doing that!

Code Contracts

Awesome but not released yet. 8o)

In the next post I'll start to plan out what I want from the fluent interface and start thinking about the best way to get it.