For generations, the C# programming language has adopted ideas from dynamic languages and introduced clever ways to achieve similar features while still being a statically typed language. In C# 3.0 extension methods were introduced and while not being the exact same thing, extension methods resemble mixins found in Ruby and other languages. In Ruby you can define a mix-in on the module level. Modules in Ruby cannot include instance methods because they are not classes, but you can import modules within a class definition using the include statement. The example below shows a Ruby implementation of a mixin that declares a whoAmI? mixin method that returns the name of the class it is mixed in on.

def whoAmI?
     "#{self.class.name}"
end

s = "I think I'm a String"
s.whoAmI?

The example below shows who we can implement a similar behavior in C# 3.0 using an extension method.

public static class MyExtensions {
    // The WhoAmI method "extends" anything deriving from System.Object.
    public static string WhoAmI(this object obj) {
        return obj.GetType().Name;
    }
}
public class Program {
     static void Main(string[] args) {
           string s="Hello World";
           Console.WriteLine(s.WhoAmI());
     }
}

When we compile our “who am I” sample, the IL code emitted would is the same as for the plain old C# snippet below.

[Extension]
public static class MyExtensions {
      [Extension]
      public static string WhoAmI(object obj);
}
public class Program {
    static void Main(string[] args) {
        string s = "Hello World";
        Console.WriteLine(MyExtensions.WhoAmI(s));      
    }
}

Notice that the C# compiler erases the this modifier and tags the extension method with an Extension attribute. Notice also that the s.WhoAmI() method call is changed into MyExtensions.WhoAmI(s). Extension methods are just syntactic sugar for delegating to a static method defined on a static class.

In C# 4.0 yet another dynamic language type behavior is introduced through the new dynamic keyword. I speculated in that this feature would be introduced a while ago, and I think I got quite close on this. For those of you who haven’t had the time or opportunity to fool around with C# 4.0, this is what it looks like.

static void Main(string[] args)
{
    dynamic d = new SomeDynamicType();
    d.DoStuff("With a couple of args",123);.
}

In the example above the variable d is of type dynamic. During the PDC, anyone giving a talk on C# stressed that dynamic is a static way of saying that something is dynamically typed. In this sense, dynamic is just a type supported by the compiler. The difference is that the dynamic type appears to support any method, property, field or indexer. Naturally, the compiler cannot emit any old IL code for the operations performed on a dynamic type, so just as with extension methods, there is some compiler magic happening to make dynamic binding possible. When we use the dynamic keyword, the compiler emits a dynamic call site that defers the dispatch of the operations to runtime. To do this the Dynamic Language Runtime, which will be part of the BCL in .NET 4.0, is used. After compiling, the example above will look something like this.

using Microsoft.CSharp.RuntimeBinder;

static void Main(string[] args)
{
    // Note; I'm still wrapping my head around this stuff,
    // so this might have minor errors...
    object d = new SomeDynamicType();
    CallSite<Func<CallSite, object, string, int>> site = 
        CallSite<Action<CallSite, object, string, int>.Create(
            new CSharpCallPayload(
                RuntimeBinder.GetInstance(), 
                false, 
                false, 
                "DoStuff", 
                typeof(object), 
                new CSharpArgumentInfo[] 
                { 
                    new CSharpArgumentInfo(
                        CSharpArgumentInfoFlags.None,
                        null
                    ),
                    new CSharpArgumentInfo(
                        CSharpArgumentInfoFlags.None,
                        null
                    ),
                    new CSharpArgumentInfo(
                        CSharpArgumentInfoFlags.None,
                        null
                    )
                }
            )
        );
    }
    site.Target(site, d, "With a couple of args", 123);
}

When we create our call site, we need to specify a generic argument. This argument is a delegate type that represents the signature of the call. In our example, the call takes has a dynamic receiver, and takes a string and an integer argument. When we invoke this delegate we will invoke the C# runtime binder working with the DLR, which binds the expression based on the runtime types of the arguments and the dynamic receiver. The action encodes the type of the binding and any statically known information. For example, in our example it is statically known that the method we want to bind to should have a string and an int argument. At runtime, the C# binder queries the dynamic receiver for all its DoStuff methods and populates its symbol table for the dynamic receiver’s type. If there is an exact match on a method signature, that method will be used just like we would with plain old reflection. However, if there aren’t any exact matching methods, the runtime binder will try to coerce the arguments to types that can be used to match a signature in the same manner as overload resolution is performed in the compiler. If no match is found RuntimeBinderException with a similar error message to the ones the compiler gives us will be thrown.

That exception will also be thrown if we try to invoke an extension method on a dynamic receiver.

public class Program {
    static void Main(string[] args) {
        dynamic s = "Hello World";
        Console.WriteLine(s.WhoAmI());      
    }
}

Why does this happen? It is because of how extension methods work. As we learned at the beginning of this post, extension methods delegate their invocations to static “helper” methods. These methods aren’t declared on the type it self. When we declare a type as dynamic, we are free to invoke any operation on that method without the compiler complaining. It might very well be that the type has a WhoAmI method. However, when this method isn’t found at runtime we get an exception. So extension methods and dynamic dispatch don’t mix.

When Anders Heljberg unveiled C# 4.0 we got introduced to many new and cool language features. I’d been expecting some of them and I beat myself for not thinking of some of the others. A features that took me by surprise was the support for covariance and contra-variance in the language. Judging by the blogs I’ve read on C# 4.0, this is one of the things that many people have a hard time grokking and it’s one of those things I should have seen coming. In this post I’ll take some time to explain what these things are, and why I should have expected it to show up.

In an object oriented language, it should be completely transparent to an object if the reference to that object is to its type or one of its super types. This is the simplest form of covariance and you’ve probably used it a bazillion times in your code.

public class Superclass {
    public virtual Superclass Clone() {}
    public virtual void CopyState(Superclass other) {}
}
public class Subclass : Superclass {}

public class Application 
{
    public static void Main() 
    {
        // Subclass is covariant with Superclass
        Superclass thing = new Subclass();
    }
}

.NET has supported array covariance for reference types all the way since 1.0, so you’ve been able to assign instances of subclasses to an array which is typed to the superclass of those subclasses. You haven’t been able to do this with value types because they behave differently. To understand why, we need to remember than arrays of reference types in .NET actually are arrays of pointers, while arrays of value types are arrays of the actual structures. Structures vary in size, but a pointer is always the same since and hence pointers fit in the slots of the array regardless of what sort of object they point to. To ensure correct runtime behavior, type checks are performed when writing to an array and if you try to add a reference type that doesn’t fit, the you’ll get an ArrayTypeMismatchException.

Another area where covariance can make your brain spin is the return types from methods. Superclass in the snippet above has a virtual Clone method. When you override this in Subclass what should the return type be? In C# the answer is Superclass because you cannot have a covariant return type even if it users would expect the type to be Subclass. The CopyState method on Superclass accepts superclass as its argument and when we override this in Subclass we must also stick to Superclass as its argument. This is what is known as contra variance. This is in line with Liskov’s Substitution Principle and fits nicely with the axiom that “one should be liberal with what one accepts and conservative with what one sends”.

Since the days of C# 1.0 generics have been introduced on the platform and this has changed the game a little, and it is here the new covariance and contra variance features in C# 4.0 come into play. Today, you can use interfaces or delegates in ways that don’t seem intuitive from the perspective of the user.

delegate T Func<T>();

public class Application 
{
    public static void Main() 
    {
        Func<Superclass> superclassFn = () => new Subclass();
    }
}

Unless you’re a true C# geek, one would expect the example above should compile because Subclass “is a” Superclass, but it doesn’t because delegates in C# 2.0 are not covariant. In C# 4.0 we’ll be able to add the out keyword to the generic type parameter to make the example above work.

delegate T Func<out T>();

And you can do the same for interfaces, allowing the type argument T only to be “sent” by the methods declared on the interface.

public interface IReader<out T>
{
    T Read();
}

Contra variance is also supported through the in keyword. When this is used the type argument can only be used for arguments.

public interface IWriter<in T>
{
    void Write(T thing);
}

Those of you who are familiar with Java 5 know that also has support for variance with generics, but this is a different kind of variance. C# 4.0 supports “definition-site generic variance”, while Java supports “use-site generic variance”. To explain the difference, consider this Java example using Java equivalents of the classes from before.

public class Container<T> {
    private T value;
    public T getValue() { 
        return value; 
    }
    public void setValue(T value) {
        this.value = value;
    } 
}

public class Application {
    public static void main() {
        Container<Subclass> subContainer = new Container<Subclass>();
        Container<? extends Superclass> covariantContainer = subContainer;
        Superclass instance = covariantContainer.getValue();

        Container<Superclass>> superContainer = new Container<Superclass>();
        Container<? super Subclass> contraVariantContainer = superContainer;
        contraVariantContainer.setValue(new Subclass());
    }
}

In this example we first employ the ? extends Superclass wildcard to make the container covariant with anything that extends Superclass which enables us to get the value as a Superclass from that container even if the container was of Subclass in the first place. In the second paragraph we turn it around and use contra variance for the argument to the container.

Expect for anonymous inner classes for which delegates is a better solution, Covariance and contra variance was the last feature Java had, that C# didn’t. So one might think that this has been a long time coming, but in fact in a .NET perspective this has been around for a while. The CLI has had support this since generics where introduced. Section II 9.5 in the CLI specification covers this and the only difference from C# 4.0 is that + is used to denote covariance and - is used to denote contra variance. In fact, you can run this IL code on the CLR today to use these features.

assembly extern mscorlib {}
.assembly VarianceExample {}

.class private auto ansi beforefieldinit Superclass extends [mscorlib]System.Object {}

.class private auto ansi beforefieldinit Subclass extends Superclass {}

.class interface private abstract auto ansi ICovariant`1<+T>
{
  .method public hidebysig newslot abstract virtual instance !T GetStuff() cil managed {}
}

.class interface private abstract auto ansi IContraVariant`1<-T>
{
  .method public hidebysig newslot abstract virtual instance void  DoStuff(!T 'arg') cil managed {}
}

.class private auto ansi beforefieldinit Application extends [mscorlib]System.Object
{
  .method private hidebysig static void Main() cil managed
  {
    .entrypoint
    .locals init (
             [0] class ICovariant`1<class Subclass> subCovariant,
             [1] class ICovariant`1<class Superclass> superCovariant,
             [2] class IContraVariant`1<class Superclass> superContraVariant,
             [3] class IContraVariant`1<class Subclass> subContraVariant)
    ldnull
    // Put ICovariant<Subclass> on the evaluation stack
    stloc.0
    ldloc.0
    // Put IConvariant<Superclass> on the evaluation stack
    stloc.1
    ldnull
    // Put IContraVariant<SuperClass> on the evaluation stack
    stloc.2
    ldloc.2
    // Put IContraVariant<SubClass> on the evaluation stack
    stloc.3
    ret
  }
}

This is why I should have seen this feature coming. After all, all the C# team has done is to add language support for a feature that was already there.

When I was actively working on my Quaere project, I experienced a real slowdown in productivity when I got to the more complex processing of its expression trees. The main reason for this was that the visitor implementation we used for this grew very large over time. Below you can see the interface definition, and the Quaere for Objects query engine’s implementation of this interface is no less than 940 lines long.

public interface ExpressionTreeVisitor {
    public void visit(FromClause expression);
    public void visit(GroupClause expression);
    public void visit(JoinClause expression);
    public void visit(OrderByClause expression);
    public void visit(DeclareClause expression);
    public void visit(WhereClause expression);
    public void visit(SelectClause expression);
    public void visit(QueryBody expression);
    public void visit(QueryContinuation expression);
    public void visit(QueryExpression expression);
    public void visit(BinaryExpression expression);
    public void visit(TernaryExpression expression);
    public void visit(UnaryExpression expression);
    public void visit(Constant expression);
    public void visit(Identifier expression);
    public void visit(MethodCall expression);
    public void visit(Indexer expression);
    public void visit(Statement expression);
    public void visit(Parameter expression);
    public void visit(NewExpression expression);
}

The implementation is the classic depth-first, double dispatch visitor used by virtually every one who needs to walk an abstract syntax tree. For those of you who might be unfamiliar with this pattern, a visitor is a way of separating an algorithm from the object graph it operates on. The practical benefit of this pattern is the ability to add new operations over existing graphs without modifying the classes making up the graph. The Visitor pattern is not one I often use, because it comes at a price. The set of classes to visit and the return type of the visitor must be known in advance, and they must each have the so called Accept method. Because of this, every visitor must change whenever the visitors working on that graph must also change, even if the visitor is unaffected by the change. Another big issue with the vanilla Gang of Four implementation of the pattern is that it cannot be applied to graphs that haven’t been designed to have the Accept methods required to pass control from the node to the concrete visitor. In a sense, the Visitor acts as a repository for the methods to be performed on the graph, and when the node accepts the visitor the type of the node is used to determine the appropriate overload on the visitor class to use. This is what is known as double dispatch. As you can see in the example above, the visitor declares an overload for each of the node types it is able to visit.

Even if the implementation of the pattern is a little tedious and inflexible with regard to changeability, my biggest challenge with Quaere was that algorithms for all of the nodes had to be in the same class and that recursive calls using the visitor can be a little obscure. Delegation can be a solution for the first problem, but this doing this makes the obscures the recursive code even further.

In my “Better Domain Driven Design talk” I make a point that when our programming languages evolve, so should our implementation of common design patterns. We’ve come a long way from C (which is the language used in the Gang of Four book) to C# 3.0 which is what I’ll be using here. Note to the Java guys reading, I’ll do something similar for Java quite soon - I just need you to build up some generics envy first.

Through out the years, there have been many takes on improving the Visitor pattern. Some have been good, some not so good. In my example I’m going to show you how to combine a service locator with a different implementation of the visitor pattern to walk a LINQ expression tree. This is kind of relevant to the problem described earlier, because LINQ was the inspiration for writing Quaere. Implementing a visitor for LINQ expressions is a “fun” challenge, because this is one of those scenarios where there aren’t any Accept methods around one can pass a visitor to. There is an ExpressionVisitor class in System.Linq.Expressions, but sadly this is an abstract internal class. Microsoft also has an example of how to write your own on MSDN, but this implementation uses a huge switch-case to mimic multimethods which makes our implementation even bigger, and thats not what I’m aim for here.

First of all, we’ll need to have an expression tree to play with…

BinaryExpression twoPlusTwo = Expression.Add(Expression.Constant(2), Expression.Constant(2));

Then we’ll need to define an interface for our visitors…

public interface IExpressionVisitor<T> where T : Expression
{
    void Accept(T expression);
}

We’ll be writing a visitor that prints out the nodes of the tree to the console, so let’s get going by implementing a visitor for the abstract Expression type.

public class ExpressionTreePrinter : IExpressionVisitor<Expression>
{
    public void Accept(Expression expression)
    {
        Console.WriteLine(expression);
    }
}

Now, we can get a test in place…

[Test]
public void CanPrintAnExpressionTree() {
    BinaryExpression twoPlusTwo = Expression.Add(Expression.Constant(2), Expression.Constant(2));
    ExpressionTreePrinter printer = new ExpressionTreePrinter();
    printer.Accept(twoPlusTwo); 
}

This looks OK, but it doesn’t really do anything useful. To achieve that we’ll need to have some less generic visitors for the different nodes. Like this…

public class ConstantExpressionVisitor : IExpressionVisitor<ConstantExpression>
{
    public override void Accept(ConstantExpression expression)
    {
        Console.Write(expression.Value);
    }
}

public class BinaryExpressionVisitor : IExpressionVisitor<BinaryExpression>
{
    public override void Accept(BinaryExpression expression)
    {
        Console.Write(" {0} ",GetSymbol(expression.NodeType));
    }

    private static string GetSymbol(ExpressionType expressionType)
    {
        switch (expressionType)
        {
            case ExpressionType.Add:
            case ExpressionType.AddChecked:
                return "+";
            // And so on...
            default:
                return expressionType.ToString();
        }
    }

Looks good, expect that a BinaryExpression has left and right hand side child expressions, and we don’t have a way to dispatch a visitor to those. To make this easy, I’m going to use the “Sandwich” design pattern and introduce an abstract class in between the interface and the concrete class.

public abstract class ExpressionVisitorBase<T> : IExpressionVisitor<T> where T : Expression
{
    public abstract void Accept(T expression);
    protected void Visit(Expression expression)
    {
        Type visitorType = typeof(IExpressionVisitor<>).MakeGenericType(expression.GetType());
        try 
        {
            object visitor = IoC.Resolve(visitorType);
            visitorType.InvokeMember("Accept", BindingFlags.InvokeMethod, null, visitor,
                                     new object[] { expression });              
        } 
        catch (ComponentNotFoundException)
        {
            // Nothing to see here.
        }
    }
}

Notice the Visit method above. This is where the real magic happens. The first line makes a generic type for IExpressionVisitor<T> where T is the type of the Expression passed as an argument to the method. It then goes on, in the second line, to resolve an implementation of the visitor from the IoC container. I’m using Rhino Commons here, but you could use just about any container that has support for generics. The last line invokes the Accept method on the recently resolved visitor implementation and passes the expression as an argument. By using a container, we’ve managed to split the visitors into tiny fragments rather than clumping them all together in one big-ass class as we would with a more traditional approach.

For those familiar with the visitor pattern, you might miss the notion of the graph accepting the visitor in the test we saw earlier, so let’s throw an extension method into the mix to make it look like a plain old visitor.

public static class VisitorExtensions
{
    public static void Accept<T>(this T expression, IExpressionVisitor<T> visitor) where T: Expression
    {
        visitor.Accept(expression);
    }
}

Finally, let’s look at what the entire test looks like using both the container and the extension method.

[TestFixture]
public class ContainerDelegatingVisitorTests {
    [SetUp]
    public void Setup() {
        // First we setup the container and
        // register the different visitors in it.
        IoC.Initialize(new WindsorContainer());
        IoC.Container.AddComponent("BinaryExprVisitor", typeof(IExpressionVisitor<BinaryExpression>),
                                 typeof(BinaryExpressionVisitor));                              
        IoC.Container.AddComponent("ConstExprVisitor", typeof(IExpressionVisitor<ConstantExpression>),
                                 typeof(ConstantExpressionVisitor));
  }

  [Test]
  public void CanPrintAnExpressionTree() {
      BinaryExpression twoPlusTwo = Expression.Add(Expression.Constant(2), Expression.Constant(2));
      twoPlusTwo.Accept(new ExpressionTreePrinter());
      // I assert you that this works. Sorry for not writing a real test.
  }

}

There you go, this is the classic Visitor pattern revisited for C# 3.0. It might not be as fast an old school visitor since it is using containers and a bit of reflection, but it is faster than other generic visitor implementations such as the “Walkabout” pattern. However, a speedy implementation is not what I’ve been aiming at here. I wanted to separate my visitors from each other and extend the behavior with new visitors with little fuzz. And that, it does…

In both my “Better Domain Driven Design” and “Want SOA? Throw out your Web Services!” talks I’ve referred to the “Onion Architecture” as a mean for controlling your dependencies. The term was coined by Jeffery Palermo in his series of blog posts on it..

This style of design has come about as a consequence of our use of the Dependency Inversion Principle and it helps us achieve maintainable application architectures by relying on abstractions rather than lower level modules. For the a walkthrough of the pattern, read the blog posts by Jeffery. They are excellent.

Unless you want the pain of using Java’s broken date and time types, the domain model within a Java application will have a dependency on Joda Time and a .NET application’s repository implementation is likely to depend on NHibernate. A common question I get whenever I give one of these talks is what to do with library dependencies? Where should they be in the layers of the onion? A thing I’ve noticed is that people never ask about where platform provided libraries like .NET’s System.dll should go. The reference is always to things that you’ll have to make a conscious choice of using. In essence, there is no difference between having a dependency on a library written by Sun or Microsoft, and one written by bright developers on their spare time. It’s still a dependency. What we need to realize is that the onion architecture does not prescribe which deployment units our applications should have, but only how the different parts of our applications fit together and what abstractions we need to achieve the right level of maintainability.

Jeremy Miller recently wrote a rant on the common misconception that having your classes in separate assemblies (or JARs for you Java guys) implies that you have a loosely coupled design. This also applies to the onion, its not about physical separation, its about logical separation. You don’t need to deploy your components in a distributed environment to have a layered architecture, neither do you have to have types that shouldn’t depend on each other in separate assemblies or JARs. In fact you are much better off having everything in one place until you actually need to separate them because it will be easier to work with the codebase, it will compile faster and you don’t have that many artifacts to deploy.

So what about library dependencies? Just have them where every you actually need the library, and if your view suddenly depends on ADO.net no amount of physical separation will help you - its your logical architecture that sucks.

Last year I wrote a lengthy guide from the trenches on how we can make unmaintainable code better. Lately I’ve often found myself caught between a rock and a hard place, doing my best to make the best out of untestable, incomprehensible stacks of code. As Bill Pierce pointed out in the comments to my previous blog post, such a task can be daunting. One of the things I find most difficult is figuring out where to start. Starting at an edge and nesting yourself into the code is a way to get going, but how do you find that edge when the code is hard to comprehend? Brian Eno and Peter Scmidt’s Oblique Strategies deck of cards has often been a source of inspiration for me when doing this kind of work.

The Oblique Strategies deck of cards was first published in 1975, and is now in its fifth edition. The deck was created as a tool to break creative blocks after Eno realized that he wasted costly studio time pondering over different things. Each card contains a phrase or cryptic remark which can be used to break a deadlock or dilemma situation. I’ve often regarded computer science as a creative craft, and doing nothing in a recording studio is just as wasteful as starting hopelessly into your computer screen trying to figure out what to do.

“These cards evolved from separate observations of the principles underlying what we were doing. Sometimes they were recognised in retrospect (intellect catching up with intuition), sometimes they were identified as they were happening, sometimes they were formulated. They can be used as a pack, or by drawing a single card from the shuffled pack when a dilemma occurs in a working situation. In this case the card is trusted even if its appropriateness is quite unclear…”

From the introduction to the 2001 edition of Oblique Strategies

Many of the cards have phrases that relate directly to refactoring. For instance “only one element of each kind” inspires me to go looking for repetitive chunks of code and make it DRY. “Bridges; -build -burn” can be a hint to look for over or under-engineered designs, “Accretion” makes me look for places where another layer of indirection might be appropriate and “You can only make one dot at a time” is a clue that I should abide the Law of Demeter. There’s even the “tidy up” card which reminds you that refactoring is needed.

The printed decks are hard to find and if you strike luck on eBay, it will set you back $40 or more. Luckily, there are other options. You can download this PDF and print your own Oblique cards, get this dashboard widget for your Mac or carry a virtual deck on your iPhone like I do.

Now it’s time to consult the deck on whether this post is done or not.

I guess so…

Back in September I gave a talk entitled “Better Domain Driven Design” at the JavaZone conference in Oslo. The recording of that talk is now available on the JavaZone web site. Just click the “Presentation” link on this page to watch it. Unfortunately my super cool opening titles aren’t in the video because the frame grabber they used didn’t capture 25 frames per second, but fear not you can catch that one here. So to get it all in the right order, watch this YouTube video and then swiftly click the link on the JavaZone agenda page.

Lars Wilhelmsen just wrote up a list of the stuff he’s got going in his tricked out Visual Studio 2008 installation. He tagged me, so here is the lowdown of what I’m rolling with.

I’ve always tried to stick to a few tools that I know well rather than running amok with add-ins. Hence there are few surprises in my setup.

• The theme is a slightly customized version of John Lam’s brilliant port of the VibrantInk TextMate theme. I love Vibrant Ink so much that I’ve ported it to IntelliJ IDEA also.
  
• Since I’m a TextMate addict (I’m writing this in TextMate) the font is of course Monaco.
  
• It goes without saying that I’m using JetBrains ReSharper 4.1. Since I’m running Visual Studio on my Mac, I’ve changed some of the key strokes so that they resemble those in IntelliJ, for instance the generate function usually found on Alt + Insert is underneath Control + Enter on my machine.
  
• Test Driven .NET takes care of all my testing needs and NCover tells me whether I’ve been good or bad.
  
• Assembla keeps my code safe and VisualSVN gets my code in and out there.
  
• To get the best possible OS X look on my Visual Studio I’m running a minimal version of Windows XP in Parallels with the Leopard XP BricoPack installed.

So what about short cuts I cannot do without? For starters, Shift + Alt + Enter could have been on the list, but I’m forcing my self to not mouse around by running Visual Studio without any toolbars. That said, I consider myself a R# black-belt so take a look at the Mac IntelliJ keymap. I’d rather tell you about some of the Live Templates I’ve got on. Whenever I do something more than a few times, I take my time to DRY up and create a template for it. For instance I create new NUnit tests by writing NUT and hitting Tab, I even wrote a template for Ayende’s Hack Bomb’s. The same applies to file templates, in addition to the vanilla interface, class and so on, I have templates for WCF contracts, NHibernate HBM maps and lots of other stuff.

Today’s best sellers in the world of business books are not like they were a decade ago. While the most influential writers had their background from magazines like The Harvard Business Review some years ago, today they’re more likely to write for The New Yorker or Wired. Writers like Malcolm Gladwell and Chris Anderson have skyrocketed as the leading thinkers in the world of business literature, and even tapped into the larger consumer market with their astute observations of the business world. Their secret is to follow the old axiom of simplifying and exaggerating rather than being too concerned with complications. I do the same with many of my talks, and just like milestone books like “The World is Flat” and “The Long Tail”, I too have been criticized for not having a balanced enough presentation of my material. This is very apparent on the ratings for my “Want SOA? Throw out your Web Services!”-talk on the ongoing MSDN Live tour. The ratings I get are very polar, most people give my talk a four or five (on a one to five scale), but quite a few give me a one. Surprisingly there are very few in-between. I’ve shaped this talk to provoke a reaction and challenge the way most people think about SOA. I also know that my full-on attack on established “best practices” for service oriented architectures is uncomfortable for those who have spent time and money building their SOAs to these principles. My question to you is do you see any return on investment?

Even if it might seem like it when I give the talk, I’m not offering a panacea for all your SOA challenges. I am however showing you a different way of thinking about service orientation than the too-tired reuse oriented layered web services model. Hopefully this gets you thinking about whether the SOA we’re used to really solved the challenges it addressed, or if we’ve been lured into a vendor trap where the solution to one technical problem just unveils two more.

I think Torbjørn nailed it in his latest Contiki Strip installment, don’t just do something because I or anybody else tells you so.

JavaZone is only one week away. This year I'll be doing a talk how we can improve our designs to achieve better separation between business and infrastructure concerns. These teasers have been leaked to YouTube a while ago, but with just one week to go, time has come to bring them to the masses.

So credit is due to Udi for the second teaser, I essentially remixed the Yoda slide from his Intentions and Interfaces talk. Udi; I'll send you the HQ version of the clip if you're keen on using it in future versions of your talk.

Looking forward to seeing (many of) you next week!

Last weekend I met with Johannes for a couple of beers at Mono. As always, our discussions got quite esoteric and one of the things we talked about was weird computer science books. If you’re anything like me, you steer away from the mass produced “Teach yourself something in 24 hours” titles and head for the ones that really stand out. In the wake of our discussion I figured I’d write up the “Anders Norås Guide to Weird Computer Science Books” so here goes.

Max Objektorienterar

First off is the Swedish classic “Max Objectorienterar”. This is a children’s book about young Max who explores the wonderful world of object oriented programming. The book has wonderful illustrations by Eva Eriksson depicting childish UML diagrams.

There is also an English translation of the book available, but this one is not as good as the original Swedish title because the names of OO concepts don’t resemble English names in the same way they do in Swedish. “Titta Arve” has the double meaning of “Look Arve (name)” and “Look, inheritance”.

(Yes. I know this is not a real book, but it is still better than most teach yourself OO titles.)

The Little Schemer

The Little Schemer by Daniel P. Friedman and Matthias Felleisen is by all means a serious computer science title, but the style of writing and the illustrations in the book are very different from what you’re used to.

I first got introduced to this wonderful book when my ex-girlfriend studied informatics for humanists at the University of Oslo. At this course they wrote little Scheme programs to learn how to think logically - something my ex really could get better at. Just like Scheme, the book is a little challenging at first, but once you get used to it you’ll be reading the lambda expressions like your ABC. Here is an example taken from the book to give you a feel of what this is about:

Are you in the mood for caviar?                  Then we must go looking for it.

What is (looking a lat)                          #t, 
    where a is caviar                             is obviously in lat.
    and 
        lat is (6 2 4 caviar 5 7 3)

(looking a lat)                                  #f
where a is caviar
and
    lat is (6 2 grits caviar 5 7 3)

Where you expecting something different?         Yes, caviar is still in lat.

True enough, but what is the first number        6.
in the lat?

And what is the sixth element of the lat?        7.

And what is the seventh element?                 3.

So looking clearly can't find caviar.            True enough.
                                                     because the third element is grits, which
                                                     doesn't even resemble caviar.

Here is looking                                  We did not expect you to know this.
  (define looking)
    (lambda (a lat)
      (keep-looking a (pick 1 lat) lat)))

Write keep looking.

Strange isn’t it? The Little Schemer is the follow up to The Little Lisper. There are also a few other interesting titles in the series, all written in the same quirky style. Here is an excerpt from “A Little Java, A Few Patterns”:

Let's define more Seasioning                     We can have lots of Seasonings
class Thyme extends Seasoning {}                 class Sage extends Seasoning {}

Quirky recursiveness topped off with lots of cute drawing of elephants and mice, or dancing coffee cups if you’re more into Java than functional programming, explaining the fundamentals of programming makes a perfect combination.

Mr. Bunny’s Big Cup O’Java

“Let me guess,” said Mr. Bunny. “This time it’s Java.”

“How did you know?” asked Farmer Jake. He wondered with a flush of embarrassment if all his predicaments were so predictable.

“Are you going to tell me Java is a new way of controlling my pixels?” asked the farmer, proudly remembering his last adventure with the bright little bunny.

Farmer Jake could still say “pixel”!

“Oh, Java is designed to control much more than your pixels.” said Mr. Bunny. “Java is a new way to control that big fertilizer company in Redwash County.”

Farmer Jake nodded thoughtfully.

“Jake makes a simple promise to the programming community.” continued the rabbit.

“That we’ll be free at last?” asked Farmer Jake.

“That you’ll never run out of work.” said Mr. Bunny. “With Java, programs can be written once, and can break on almost any platform.”

Mr. Bunny quickly sketched a diagram in the dirt.

“Wow,” said Farmer Jake. “Is it really that easy?”

“Sure”, said Mr. Bunny with a wink. “Now let’s sin a little song.”

And so Mr. Bunny began to sing, and Farmer Jake sang along, to the tune of “When You Wish Upon a Star.”

If Daniel P. Freidman’s style isn’t quite you’re cup of tea, maybe a big cup of Java is the way to go? “Mr. Bunny’s Big Cup O’Java” by Carlton Egremont is another favorite of mine.

You won’t learn a thing about Java programming from reading this book, but you’ll laugh your heart out. The illustrations used through out the book are spot-on satire on the too tired square, triangle and circle ones we see in technical books, documents or articles every day. The examples used to explain the different concepts in the language are hilarious, for instance interfaces are explained through a story of a guy who is the major, the sheriff, a painter and a load of other things at once. Coming to think of it, no other book ever has made the concept of interfaces as roles as clear as “big cuppa” does.

Mr. Bunny’s Guide to ActiveX

In Visual Basic, you form windows using forms. A form is a window that you form. At first forms are unformed. You must form your forms using the form designer (formerly the former). In the form former, an unformed form forms a uniform formation….

Mr. Bunny’s Guide to ActiveX was the first of the Mr. Bunny series, and it is even more hilarious than the Java title. It is in this book we get introduced to the most basic building block in computer software, which is referenced opening of the “Big cuppa” book (above), the pixel. Just like the other Mr. Bunny book, this is a nonsensical book on ActiveX programming filled to the rim with injokes on the technology. There are jokes on every aspect of Windows programming, and you’ll find answers to questions you never though you’d ask like “How is ActiveX diffrent from ActiveY?”. Egremont even manages to be funny about CLSIDs - pure class!

I am a Bug

Robert Sabourin’s I am a Bug is a picture book illustrated by his 12 year old daughter intended for parents in the software business who want to explain what they do to their kids. The book is focused at the quality assurance aspects of our trade, and it is just as useful when explaining QA to executives as when explaining to children.

Mommy, Why is There a Server in the House?

“When daddy loves mommy very much, he buys her a stay-at-home server.” Speaking of children’s books, we can’t forget Dr. Tom O’Connor’s excellent “Mommy, Why is There a Server in the House?”.

This book is not a real children’s book, but rather clever marketing for a Microsoft product. If you don’t feel like spending $6 on marketing material, you can always read it online at: http://www.stayathomeserver.com/book.aspx

Why’s (poignant) guide to Ruby

While I felt like I was high on some weird drug many a time whilst writing this guide, there is no book more spaced out than “Why’s (poignant) guide to Ruby.”. This one is just plain and simple ridiculously funny, with the added bonus that you might actually learn a thing or two about Ruby along the way. This book is packed with weird and wonderful drawings, photo montages and cartoons, quirky code samples and lots of humor. This is a must-read for any developer, and whether you actually care about Ruby or not doesn’t really matter.

Treat yourself and go off to read some of these titles. They are much funnier than this sad blog ever will be. Who knows, maybe you’ll learn something as well?

Quite a few .NET based Composite Oriented Programming spikes have surfaced in the wake of my humble COP spike last week. I was by no means the first to implement this concept on .NET and most of the other spikes were written long before I posted mine. As far as I know Fredrik Kalseth was first to the flag when he wrote about it back in February and he made his code available when he revisited the topic last week. Fredrik ended up in the experimental field of COP after having explored AOP by rolling his own AOP framework. Writing an AOP framework is a fun way to learn lots of things about low-level .NET stuff. I have witnessed all of the challenges with implementing Castle’s Dynamic Proxy, and I would recommend that using this rather than building your own to anyone who gets serious about building a COP framework. Henry Luk, who was the second to do COP on .NET, used Castle Dynamic Proxy and his code is very similar to what my stuff looked like before I added support for references within the composites.
Yves Goleven wrote his COP POC (look anagrams!) with .NET’s own RealProxy and like me he keeps a registry of the “traits” to support dispatching to the pieces of a composite.
The last to join the party was Magnus Mårtensson. Magnus built his “framework” on top of the Unity container and he too used the RealProxy for his proxying needs.
From what I can understand, Magnus is quite determined to go forward with writing a full fledged COP framework. Magnus works for Jayway’s sister company Dotway, and Jayway is of course where the whole Qi4j thing started so Magnus is likely to get the corporate backing needed to take on such a challenge.
There has been some speculation on whether I will get more serious about Qi#, and even if I kind of feel the urge, I won’t do it now for a couple reasons.

I already have my Quaere project which I haven’t been able to do any serious work on for a long time - my apologies to Michael Hunger for bringing that project to an abrupt stop. This was partly because of personal decisions and me not being able to use the stuff I was building in my daily work. I used bits and pieces of Quaere for forthcoming talk at JavaZone and I really want to get that show rolling again soon. I just need to find a way to make me able to be more committed than I am today.

The other reason is more interesting, even though this is more or less pure speculation. On PDC this year Anders Hejlsberg will do a breakout session on the future of C#. The last time he did this he unveiled LINQ and I suspect we have something related to COP coming.

C# 4.0 will have support for dynamic dispatch. The behavior will be similar to Visual Basic’s late binding feature and one of the key motivations for adding it is to improve interoperability with types written in dynamic languages running on the Dynamic Language Runtime. A cool side effect of having dynamic dispatch support in C# is that it will make reflective method invocations much easier to do. Rather than having to go down the tiresome road of getting a MethodInfo from a type and then invoking that method on an instance, we should be able to surround a block with the suggested dynamic keyword and do this:

dynamic
{
    object myComposite = compositeFactory.Create();
    myComposite.sayHello();
}

As with Visual Basic’s late binding, the method invocation would of course be bound to an object instance, and hence it would not be as dynamic as Boo’s IQuackFu feature or Ruby’s method_missing. Still, having this kind of dynamic dispatch support would be a step in the right direction for getting intrinsic Composite Oriented Programming support in the language.

While the dynamic keyword isn’t set in stone, dynamic dispatch is more or less a confirmed feature in C# 4.0, but there is another thing I suspect my namesake will unveil in Los Angles this October that is even more interesting…

One of the ingenious things that make LINQ work is the expression trees that are constructed at runtime. These can be inspected, altered and transformed just like the abstract syntax trees used by compilers, they can even be compiled into IL code by invoking the tree’s compile() method. When you think about it, LINQ’s expression trees is a convenient way to build IL code at runtime. This can be extended to also cater for runtime construction and compilation of other structures at runtime, and in a sense this exactly what we’re aiming at with composite oriented programming. Keeping in mind that many of the features we’ve seen in the two latest incarnations of C# are adopted from dynamic languages, I don’t think it is too far fetched to speculate that some form of dynamic object construction will be part of C#.

In combination with dynamic dispatch, such a feature would cover a most of the usage scenarios for COP. There might be some shortcomings with regard to more advanced features such as side effects, but then again C#’s event support covers partially for this.

If dynamic construction becomes part of C#, I’m not going to invest a lot of effort into building a COP framework for .NET. This is the second reason why I won’t start developing such a framework now. I might be wrong in my speculations, and if so could I would be happy to contribute to such a project as long as I’ve got my challenges with being committed to Quaere get sorted. We'll know for sure in October.

My quick and dirty Composite Oriented Programming spike seems to have gotten quite some attention around the blogosphere, so I better keep my promise and publish the source code. The source code can be downloaded from http://andersnoras.com/files/folders/code/entry595.aspx.

Please keep in mind that this thing was hacked together in about an hour, so be gentle with me when it comes to robustness.

Last year, Rickard Öberg unveiled his Qi4j project. Qi4j is a framework for domain centric development thru Composite Oriented Programming (COP). Composition of larger objects from finer grained fragments is one of the core principles of this paradigm, and Qi4j does it by piecing together mixins to form instances.
Some of you might be familiar with traits which is a very similar concept. Traits are a simple composition mechanism for structuring object oriented programs. Essentially, a trait is a behavioral building block which is the primitive unit of code reuse. Traits have been implemented in a number of programming languages, and there is even a Microsoft funded research project which explores traits as a C# feature.

Since the 3rd pre-release of Qi4j hit the streets earlier this month, the buzz around the framework has increased, and I decided to blow the dust of a small prototype I started thinking about when I last met Rickard for a couple of beers and a lot of geek-speak. I must admit that I find the idea of composing large scale behavior from tiny, specialized bits and pieces, especially because the way sound design principles force their way into ones code.
Qi4j is a full fledged framework built on the patterns described in Eric Evans’ seminal Domain Driven Design book, and if you look at demos on their site you’ll notice that many of the mechanisms in the book manifest themselves clearly in the code. My humble demo does not feature all of the Qi4j concepts, but it does show how one can do instance composition in C# with a little help from Castle Windsor.

Before digging in to the nitty-gritty details of how it actually is done, lets take a look at how we can compose some “traits” into a composite.

Since the “traits” are behavioral in nature, we begin by describing them as interfaces.

public interface IDialogSettings
{
    string Name { get; set; }
    string Phrase { get; set; }
}

public interface ISpeaker
{
    string Say();
}

Those who are familiar with Qi4j probably recognize these from the Hello World demo. The IDialogSettings describes the state part used by the composites, while the ISpeaker interface describe the ability to “say something”. The implementation for IDialogSettings is straight forward, so we can safely skip that and look at the ISpeaker implementation (which is kind of straight forward as well).

public class Speaker : ISpeaker
{
    private IDialogSettings settings;
    [This]
    public IDialogSettings Settings
    {
        get { return settings; }
        set { settings = value; }
    }

    public string Say()
    {
        return string.Format("{0} says \"{1}\".",settings.Name,settings.Phrase);
    }
}

Notice that the implementation has a dependency on IDialogSettings that is not part of the interface and that this property is marked with the mysterious This attribute. This is a marker which is used to bind to other “traits” on the same composite. More on this when we look behind the scenes. Finally we describe the composite with yet another interface;

public interface IWorldGreeter : ISpeaker, IDialogSettings {}

Composition happens at runtime, so we’ll need to register the “traits”, the composite and the Qi# facility in the container.

<castle>
  <facilities>
     <facility id="qisharp.facility"
               type="Noras.Sandbox.QiSharp.CompositeFacility" />
  </facilities>
  <components>
    <component id=”settings”
 
             service=”Noras.Sandbox.QiSharp.IDialogSettings”

              type=”Noras.Sandbox.QiSharp.DialogSettings”
 
             lifestyle=”Transient” />
    <component id=”speaker”
               service=”Noras.Sandbox.QiSharp.ISpeaker”

              type=”Noras.Sandbox.QiSharp.Speaker”
 
             lifestyle=”Transient” />
    <component id=”greeter”
 
             service=”Noras.Sandbox.QiSharp.IWorldGreeter”
               isComposite=”true” />
  </components>
</castle>

We can resolve a composite instance just like any other type;

    IWorldGreeter helloWorld = container.Resolve<IWorldGreeter>();
    helloWorld.Name = "Marvin";
    helloWorld.Phrase = "Hello World!";
    Assert.AreEqual("Marvin says \"Hello World!\".", helloWorld.Say());

As you might suspect, the instance is a proxy. Lets take a look at the component activator responsible for creating composite components.

protected override object InternalCreate(CreationContext context)
{
    ProxyGenerator gen = new ProxyGenerator();
    Type compositeInterface = context.Handler.ComponentModel.Service;
    Dictionary<Type, object> traits = new Dictionary<Type, object>();
    foreach (Type traitInterface in compositeInterface.GetInterfaces())
    {
        object traitImpl = Kernel.Resolve(traitInterface);
        if (traitImpl != null)
        {
            traits.Add(traitInterface, traitImpl);
        }
    }
    // Wire internal dependencies...
    foreach (object trait in traits.Values)
    {
        Type traitImplType = trait.GetType();
        foreach (PropertyInfo property in traitImplType.GetProperties())
        {
            if (Attribute.IsDefined(property,typeof(ThisAttribute)))
            {
                if (traits.ContainsKey(property.PropertyType))
                {
                    property.SetValue(trait,traits[property.PropertyType],null);
                }
            }
        }
    }
    object proxy = gen.CreateInterfaceProxyWithoutTarget(
                                   compositeInterface, 
                                   new CompositeInvocationInterceptor(traits));
    return proxy;
}

First we create a dictionary of “trait” instances by resolving all of the implemented interfaces from the container, then we scan these for This attributes and wire the dependencies whenever we find one, regular dependencies are resolved in a regular manner. Since constructor can’t be defined on interfaces, constructor injection is not an option within the composites - hence we fallback to property injection here.

The “traits” dictionary is then passed to the interceptor instance which will be responsible for routing the method invocations on the composite to the “traits” supporting the behaviors.

public void Intercept(IInvocation invocation)
{
     Type targetTrait = invocation.MethodInvocationTarget.DeclaringType;
      if (traits.ContainsKey(targetTrait))
      {
          invocation.ReturnValue = invocation.Method.Invoke(

                              traits[targetTrait],
                               invocation.Arguments);
      }

}

We discover which “trait” the method was invoked on by finding the type the method is declared on, then we get that “trait” from the dictionary created in the component activator. All in all it’s quite simple.

To give you a taste of how powerful composite oriented programming can be, let’s throw a little “trait” reuse into the mix.

ITeleprompter teleprompter = container.Resolve<ITeleprompter>();
teleprompter.Phrase = "Hello World";
Assert.AreEqual("Say Hello World.",teleprompter.WhatToSay);
IWorldGreeter helloWorld = container.Resolve<IWorldGreeter>();
helloWorld.Name = "Marvin";
helloWorld.Phrase = "Hello World!";
Assert.AreEqual("Marvin says \"Hello World!\".", helloWorld.Say());

In this example, the ITeleprompter and the IWorldGreeter composites share the same implementation of the IDialogSettings “trait”. To put it another way, the “trait” is reused between the two composites. Since we’re using a container here, we could also change the lifestyle of the IDialogSettings component from transient to singleton, in which case the two composites would share state.

I only spent an hour on this example, so I haven’t taken the time to implement all of the other things Qi4j sport. If you’re curious, there is quite a lot of information available at the Qi4j website.

I’ll post the code as soon as I’ve found time to clean it up.

The guys at Codehaus are moving the continuous integration servers. I must say that I had a WTF-moment when this build failure notification dropped in my inbox: I find it amusing that the build failed because “all the tests passed”. The real reason was that it was unable to find Maven on the build server…

Last week I wrote a short anecdote about getting big, upfront design wrong. The next chapter is on quick and dirty fixes. You know, those hacks we do to “make something work”. These often come about after frenetic debugging session, where we debug a system into existence. Smacking a piece of drywall on top of the existing drywall is a real-world example.

Quick and dirty fixes often have side-effects and so does this. Notice that a drawer is missing? Its because it won’t fit when the wall is 1 centimeter, or about half an inch, thicker.

Fixes like these need to be done over, taking (almost) twice as long as doing it right the first time around.