One method of such a Guard class could be AssertNotNull() which checks, if a given method argument equals null and if true throws an ArgumentNullException. By the use of Expressions the parameter to check can be given to AssertNotNull() in a very elegant way:

public void MyMethod(SomeType elem)
{
    Guard.AssertNotNull(() => elem);

    // actual method logic
}

Through evaluation of the Expression the AssertNotNull() method is able to extract both the name and value of the argument. Thus there’s no necessity to provide both as parameters to AssertNotNull(). Moreover you do not need to provide the argument name as string.

Value by compilation

It’s very easy to extract the argument value through compilation and invocation of the Expression. Hence this solution is often taken by developers who work with Expressions in this way. The following snippet shows this implementation:

public static class Guard
{
    public static void AssertNotNull<T>(Expression<Func<T>> selector)
    {
        T value = selector.Compile().Invoke();
        if (value == null)
        {
            string name = ((MemberExpression)selector.Body).Member.Name;
            throw new ArgumentNullException(name);
        }
    }
}

Value by evaluation

In the conversation with my colleague we caught the point that the extraction of the argument value from an Expression is even possible without performing the costly compilation. This is enabled by converting the Expression into a ConstantExpression, from which we can catch the value by executing GetValue() on a FieldInfo instance:

public static class Guard
{
    public static void AssertNotNull<T>(Expression<Func<T>> selector)
    {
        var memberSelector = (MemberExpression)selector.Body;
        var constantSelector = (ConstantExpression)memberSelector.Expression;
        object value = ((FieldInfo)memberSelector.Member)
            .GetValue(constantSelector.Value);

        if (value == null)
        {
            string name = ((MemberExpression)selector.Body).Member.Name;
            throw new ArgumentNullException(name);
        }
    }
}

This doesn’t look very spectacular on first sight. The code is more complicated and it’s necessary to provide a variable in the Expression. Properties and data hierarchies don’t work with this solution, but this shouldn’t be a problem when checking argument values against null. Of course with a more sophisticated solution (iterative/recursive evaluation of the Expression tree) you can enable such scenarios, but this is out of scope of this blog post…

Looking at the execution times

So what’s the point of the second solution? It’s simple: compilation is much more time-intensive! In a little runtime test I’ve compared both solutions. A call of AssertNotNull() with a valid argument (!= null) over 10.000 iterations resulted in the following execution times:

Please note the immensive time difference! The compiled solution takes more than 53 seconds, while the evaluation takes less than 0,35 seconds. This makes a time factor of more than 156, by which the evaluated solution is faster than the compiled approach.

Conclusion

When handling with Expressions you should take the execution time into account! Once a method is executed inside of a loop and you follow defensive programming and check method parameters at every place, an argument check can become an important time factor. When possible you should favor evaluation over compilation of Expressions.

Sometimes I’ve had the requirement to treat value types, where I don’t know if the value type is Nullable<T> or not. Regardless of whether the value type is declared as Nullable<T> or not, it should everytime be treat as T. Thus I’ve had to find out the underlying type of the Nullable<T>.

The following extension method on Type realizes this requirement:

public static class TypeExtensions
{
    public static Type GetBareType(this Type dataType)
    {
        if (dataType != null)
        {
            if (dataType.IsGenericType &&
               (dataType.GetGenericTypeDefinition() == typeof(Nullable<>)))
            {
                dataType = Nullable.GetUnderlyingType(dataType);
            }
        }
        return dataType;
    }
}

Currently I’m rethinking the Specification Pattern, which has been introduced by Eric Evans and Martin Fowler some time ago and got some attention in the DDD community and beyond. The intent of the Specification Pattern is to separate the logic for (e.g.) filtering an entity from the entity itself. This responsibility is encapsulated in single classes – the specifications. Those specifications are given for example to a single method Filter() on a repository, which takes care of filtering the domain model by the specifications. Thus, you bypass the need for having several special methods in your repository which take care of the actual filter operation (such as FilterByCustomerName(), FilterByCustomerAddress() etc.).

An example interface snippet for a repository of persons with a specification filter method could then be:

interface IPersonRepository
{
    IEnumerable<Person> Filter(ISpecification<Person> filterTerm);
    // ...
}

Summarized, some key benefits of the Specification Pattern are:

• Loose coupling of the filter logic from the objects being filtered,
• Single responsibility: Interface of repository/data provider isn’t polluted with lots of filter methods,
• Callers can express in a flexible way by which criteria entities can be filtered,
• Composition of specifications (e.g. by a fluent interface) yields to flexible filter queries, for example:
  [sourcecode language='c#']var filter = Filter .By(25).And(“Frankfurt”)[/sourcecode]

But now the provocative question that one could come with: Who needs the Specification Pattern in times of C# 3.0 and Expressions? This might sound disturbing at first, but let me explain…
C# 3.0 came up with the new concept of Expressions/Expression trees. This way, code can be treated as a kind of syntax tree in the program. Developers can extend the tree with additional code portions and then compile it into executable code which can be invoked.

Therefore Expressions seem to give us similar benefits for filtering as specifications do. By using Expressions, we are able to define a single Filter() method on the repository, which gets an appropriate Expression as argument. Consumers of the repository can call this method with their custom filter Expressions and thus we’ve got the same benefits: loose coupling of filter logic and objects to be filtered, flexibility for callers to provide custom filter criteria and the possibility to combine several filter criteria (several Expressions).
One could argue that with specifications we’ve got better encapsulation of the filter logic into separate classes. But this can be done with Expressions as well (e.g. by separate wrapper classes or dedicated Expression providers), so that isn’t a good argument…

The interface of a repository of persons with a filter that uses Expressions might look like this:

interface IPersonRepository
{
    IEnumerable<Person> Filter(Expression<Predicate<Person>> filterTerm);
    // ...
}

This leads again to the question: Do we still need the Specification Pattern or is it already embedded with Expressions in the language (C# 3.0) itself?

Pattern focus

First I want to mention that the intent of a pattern is not (only) to provide a technical solution, but also a conceptual guideline for a problem at hand. Thus Expressions as technical solution don’t cover the intent of the Specification Pattern. The Specification Pattern can be implemented with the help of Expressions, but that’s another point. So, directly comparing the Specification Pattern with Expressions is like an apple-pear-comparison.

Encapsulation focus

Let’s come to use cases when I would prefer the use of dedicated specification classes rather than directly using Expressions.
First as a team lead you could want to enforce the use of dedicated specification classes in your development team (thus enforce encapsulation of the filter logic). By giving Expressions or Predicates to filter methods directly,  developers would be allowed to define filter expressions whereever they want to. You don’t have the control over this process and please don’t trust your project guidelines: If developers are allowed to do something wrong, they will do.

With specifications you can force your team members to write specification classes for their requirements, which leads to enforced encapsulation. Furthermore you drive reuse of existing specification classes. Other developers are encouraged to use existing specifications, especially because of the additional effort for writing new specifications. By combining several specifications, the reusability aspect is pushed even more.

Domain model focus

Giving consumers the full flexibility of defining custom filter criteria with specifications can be very handsome in many situations. However, in other scenarios instead of giving full flexibility, you may want to restrict the set of filters for your domain model. If you focus on your domain, you perhaps want a restricted set of specifications, each with a very specific meaning in your domain! Binding such specifications to your domain model makes the purpose of your domain and how it can/should be used in terms of filtering much clearer.

Technically, in order to restrict access to a particular set of specifications, you could create sealed specification classes inside of your domain model services (same layer as repository). Consumers of the repository would be allowed to call the Filter() method on the repository with those specifications (and compositions of those), but they would not be able to create new specifications if you don’t mark the specification interface as public. This way you get two characteristics: Restricted filtering, which fits into your domain and your use cases on the one hand, and encapsulation/separation of filter logic and entities which should be filtered on the other hand.

Bottom line

This article started with an interesting and provocative question: Is the Specification Pattern obsolete? This question came up with a look at Expressions in C# 3.0. Technically you can achieve similar results when using Expressions instead of implementing the Specification classes by hand. But as the last sections have shown, in my opinion the Specification Pattern is not obsolete! As pattern it’s adding very specific value to the plain technical solution, when you take encapsulation and domains into account. Then it clearly goes beyond the technical aspect which many developers see at first sight.

Those are my current thoughts on specifications, but of course my opinions are not carved in stone. What do you think? What points I’ve missed perhaps? I’m eager for your comments!

So, covariance and contravariance are features of a programming language’s type system (not limited to C# at all). More precisely (and theoretically), they are characteristics of binary operators, which convert one type to another type. Generally if an operator changes the type in some kind, it’s called variant. If it retains the type (the type is fix), then it’s called invariant. Two types of variant operators are contravariant and covariant operators. In fact, there are other types of variance (consider dynamic typing, duck typing etc.), thus covariant/contravariant operators are just two examples for that. If an operator orders types in the way from general to more specific for any type, then it is called to be covariant. If it orders types reversely from specific to more general, then it’s contravariant.

So far the theoretical introduction. It’s pretty much saying nothing about what both terms mean in your practical coding life, isn’t it? Well… in programming languages there are two features where co- and contravariance can make sense: return type covariance and parameter type contravariance.

Return type covariance

Let’s consider the interface IClonable for a moment. It’s declared as:

public interface ICloneable
{
    object Clone();
}

If we want a class Foo to implement this interface, then it has to apply the exact same signature:

public class Foo : ICloneable
{
    public object Clone()
    {
        Foo clone = new Foo();
        // cloning implementation
        // ...

        return clone;
    }
}

Wouldn’t it be nice to have a method public Foo Clone() instead? That’s what return type covariance means. With this, the return type would be narrowed by more specific implementations or derivations. It would give type-safety to all callers of the method. Yes, this would be nice, indeed. But that’s a feature, which is currently not implemented in the C# language. The more general return type in the interface or a base class can not be narrowed on implementing or deriving classes. The same problem arises in a number of cases and on generics, as we will see later on.

Parameter type contravariance

If we got a method on an interface or base class which takes a parameter X, then contravariance is all about wanting a more general parameter in the implementation method of that interface or in a derived class. C# doesn’t support that, yet. For example, the following will not work:

class Fruit { }
class Apple : Fruit { }
class Cherry : Fruit { }
class FlavorComparer : IComparer<Fruit> { ... }

public void SortApples()
{
    List<Apple> apples = GetSomeApples();
    IComparer<Fruit> flavorComparer = new FlavorComparer();
    apples.Sort(flavorComparer);
}

FlavorComparer compares two fruits based on their flavor. Apples are fruits, so why shouldn’t they be sorted with use of the FlavorComparer? This would be nice, but Sort() needs a IComparer<Apple> and not the more general argument IComparer<Fruit>. It should be no problem for using the more general comparer, but C# doesn’t support this at the moment.

Covariance on arrays

Since the first C# (1.0), covariance on arrays is supported. Thus, one could write:

Fruit[] fruits = new Apple[10];
fruits[0] = new Cherry();

An array of a reference type can be viewed as an array of its base type or any implemented interface. That’s no problem for the compiler, it just works. But at runtime, that example would produce an ArrayTypeMismatchException and that’s what one would expect in this example. Creating apples and setting one to a cherry is no good idea.

Well, but why does it compile? That’s a historical problem. In the first version of C#, it has been designed to attract as many developers as possible and since this type of covariance worked in Java, the C# guys applied it to their language as well. Not that good idea, but that’s another story…

Covariance and contravariance on generics

Generics in C# 1.0 to 3.0 are invariant (fix). If we map the array example to generics, then the following code will not work:

List<Fruit> fruits = new List<Apple>();
fruits.Add(new Cherry());

In this case, there’s no exception thrown at runtime, but already the compiler comes up with an error message at the first line. Invariance on generics is a serious limitation of current C# versions, since it doesn’t allow many intuitively correct cases.

For example, if you have a method List<Fruit> GetFruits() on the Fruit class, which gets overridden by the Apple class, then you can’t return an instance of List<Apple>, which should be no problem intuitively. The following code on Apple is not working:

public List<Fruit> GetFruits()
{
    List<Apple> fruits = GetApples();
    return fruits;
}

The same problem arises, if we want to have a list of fruits, which should be a Union of apples and cherries, which are both fruits…

List<Fruit> fruits = new List<Fruit>();
List<Cherry> cherries = GetCherries();
List<Apple> apples = GetApples();

fruits = fruits.Union(cherries).Union(apples);

This or similar code doesn’t work as well.

C# 4.0

Having all that in mind, C# 1.0-3.0 is some kind of nerving limited in terms of covariance and contravariance. It has covariance on arrays of reference types and C# 2.0 introduced covariance and contravariance on delegates (which obviates some really annoying workarounds), but at the whole there should be better language support of those type-system features.

But a knight in shining armour is approaching: C# 4.0 arises on the horizon! But does it hold what it looks like? In fact, with C# 4.0 you have the in and out keywords, which you can define on type arguments of interfaces and delegates.

With the out keyword you can define a type parameter to be covariant. This means, that implementations of methods which return an object of this type can also return a more specific type. The standard example in this case is IEnumerable<out T>:

public interface IEnumerable<out T> : IEnumerable
{
    IEnumerator<T> GetEnumerator();
}

public interface IEnumerator<out T> : IDisposable, IEnumerator
{
    T Current { get; }
}

This allows you to write e.g.:

IEnumerable<object> list = new List<string>();

and

IEnumerable<Fruit> fruits = new List<Apple>();

It allows you to have a base type as type parameter of an IEnumerable instance and a more specific type if you assign something to it. But wait: there’s a limitation on that… out T means: no method in this interface is allowed to use T as parameter! The word “out” makes this clear and it limits the use of those covariance to just a few interfaces. For example, this cannot be set on the ICollection<T> interface (and furthermore on IList<T>, because of IList<T> : ICollection<T>). ICollection<T> includes a method Add(T item) and since no T is allowed to be used when out T is declared, that wouldn’t work. Now, most of my own generic interfaces and many .NET interfaces as well use type parameters as in- and output, so this new type of covariance seems to be not this influencing. For example, the following code would not work:

IList<object> list = new List<string>();

But why? There’s an important aspect on that and that is the same as on the array example in the paragraph “Covariance on arrays”. Having the Add() method, one could add an instance of type object to the list and that has not to be allowed:

IList<object> list = new List<string>();
list.Add(new object());  // mustn't be allowed

Sure, that’s a big limitation, but it makes sense and is absolutely necessary!

The same comes true for the in keyword. One can define an interface with type parameter in T. With that, T can only be used as type parameter and not as return value. But this brings contravariance on the type parameters to life. Having the FlavorComparer example from above in mind? That will work, if IComparer<in T> is declared by the .NET framework. The limitation of T to be set as method parameter only is necessary due to the same aspect as for the out keyword. If IList<in T> should have been declared and one defines a variable IList<string> list and calls list.Add(new object()), then it would make no sense to iterate through all list elements as string, because the inserted object is no string and would cause problems.

So in the end, the knight’s armour is not that shiny. C# 4.0 comes with some nice covariance and contravariance features, but the out and in parameters are fairly limited (and using them together is (luckily) not allowed). Many people are annoyed about that, but I don’t share their opinion. It’s a good thing to have covariance and contravariance on type parameters separated from each other! Else this would produce heavy problems as we have seen in the examples above and in the array covariance section. My opinion is, that the language designers have done a good job here. I don’t want to have some kind of ArrayTypeMismatchException on generics and thus in/out on type parameters are a good thing.

Links:

• http://blogs.msdn.com/ericlippert/archive/tags/Covariance+and+Contravariance/default.aspx
• http://blogs.msdn.com/charlie/archive/2008/10/28/linq-farm-covariance-and-contravariance-in-visual-studio-2010.aspx
• http://channel9.msdn.com/shows/Going+Deep/Expert-to-Expert-Anders-Hejlsberg-The-Future-of-C/

• Aufruf dynamischer Sprachen: dynamic-Schlüsselwort
• Optionale Funktionsparameter wie in C++ (wie ich das vermisst habe!)
• Rückgabe anonymer Typen durch Funktionen

Einen umfassenden Überblick über die Neuerungen gibt ein Word-Dokument, welches Microsoft hier zum Download bereitstellt.

Links:

• http://www.outofcoffeeexception.de/2008/10/27/C+40+Dynamic+Keyword.aspx
• http://www.outofcoffeeexception.de/2008/10/27/C+40+Optionale+Parameter.aspx
• http://www.outofcoffeeexception.de/2008/10/27/C+40+Mit+Dynamic+Anonyme+Typen+Zuruumlckgeben+Und+Verwenden.aspx
• http://blogs.msdn.com/dparys/archive/2008/10/28/neue-m-glichkeiten-in-c-4-0.aspx