Playing around with the visitor pattern

I have been thinking a little bit about the visitor pattern recently. One of my most recent applications was in combination with a class, which would be used in a message distribution scenario.

The class’ reposibility is – given a list of email addresses – to look up any existing users in my application, and allow the caller to perform an action depending on whether the email belongs to a registered user or not. Pretty simple if you feel like juggling dictionaries and stuff, but I made an even simpler solution.

My email lookup service has the following interface:

And then I have two classes: EmailRecipient and UserRecipient which are both specializations of the abstract superclass Recipient – each containing either an email (a string) or an IUser depending on whether the service was able to look up a user.

Then I have another service, which functions as a message distributor. Given a list of email addresses, either an email or an internal message will be delivered to each recipient. This is a perfect application for the visitor pattern, because it allows us to avoid this kind of brittle code:

I have seen this kind of code in far too many places where inheritance is used. It is obviously very brittle, because what happens if someone adds another kind of Recipient? Nothing at first, because the code will compile like everything is allright. Only after the code is run, and we actually get in a situation where another kind of Recipient is encountered, do we get an error… and in the example above, I was courteous and threw an exception – but what if the original author had not done that? The program could have been silently failing for months before someone found out… yikes!

Another solution is to move the behavior into the specializations – e.g. into an implementation of an abstract SendMessage method on Recipient. But then the specializations would require a reference to either the emailService or the messageService, which would kind of turn the layering upside down, since the domain classes would need to know about some higher level services.

What we really want, is for a service to be able to behave differently depending on which specialization is encountered, and for that service to contain the logic to handle each specialization. And we want errors at compile-time if a specialization is not handled. Enter the visitor pattern…

One way to accomplish this is by using the visitor pattern as described by GoF. It’s pretty simple: Make a call to an abstract method which gets implemented by each specialization, and let that specialization make a suitable callback to identify itself. My visitor interface looks like this:

– and then each specialization must implement the abstract Visit method from the Recipient class:

and then invoke their correponding callback method passing themselves back.

Then my client can create an implementation of IRecipientVisitor, supplying it with the necessary services, allowing the visitor to do different stuff depending on the specializations. But that requires me to implement a class like this every time I have a reason to do different stuff:

Having done this a few times, implementing a new class each time which would be used only once, I started thinking about how to accomplish this with fewer lines of code. One thing that really bugged me, was that I needed to supply the visitor with all kinds of context data to allow the visitor to perform whichever action it would decide to carry out, depending on which Visit(...) method would be called. Then I came up with the generic visitor:

Now my message dispatch can be implemented like this:

Why is this great?

1. I get to implement multiple dispatch with all the safety of the visitor pattern. If I add a new specialization of Recipient, e.g. ErronousEmailRecipient, I add a new method to the IRecipientVisitor interface. That causes the RecipientVisitor to break, so I implement the new method in there as well, in turn causing the code to break everywhere the visitor is used (“break” in a good not introducing bugs-kind-of-way). That way I can be sure that I will know where to handle this new specialization.

2. I get access to the context I am already in. Instead of creating a new visitor and supplying it with sufficient context to carry out whichever actions it needs to perform, I can specify in a short and concise way what I want to do for each specialization, accessing any local variables inside of the scope my labdas are in. That’s just elegant and easy.

3. The code is where it is used. The distance from usage to implementation is zero. Of course, if the implementation is more complex, it may look more like so:

– which is still pretty terse and to-the-point compared to creating an entirely new dedicated class for this.

How JavaScript’s closures surprised me

Well, it happened when I was making a web page on which the user could pick a number of time slots. The time slots would be configured using a calendar and a couple of time entry controls, and the user would add the time slot by clicking a button. The selected time slots would be stored as a JSON serialized array of time slots in an input element.

The selected time slots would be shown in a list on the page, each one with an X on the side which could be used to remove the appropriate time slot. The problem was, that it did not remove the appropriate time slot. But why?

It’s because of the way JavaScript’s closures are implemented!

You see, my code was something like this (using Crockford’s JSON library and the incredible jQuery):

What happened when I tried to remove the time slots? The most recently added time slot would get removed all the time, even though I clicked the first and the second etc.

At this point, I knew it was due to some JavaScript function closure stuff, because I could see that my click event handler would call removeTimeSlot with the id of the most recently added time slot all the time.

But why was this happening? I made all kind of changes to the snippet, moved the variables around, made several temporary variables, but the problem persisted!

Then I searched around, and I discovered two things that I did not know about JavaScript (and would not have expected):

  1. Variables reside in the function in which they are declared.
  2. Functions get the closure of their containing function.

I am a C# guy, and in C# I know that an anonymous delegate gets the closure that it needs and nothing more. I also know that variables declared inside the scope of for instance a for loop are local to that loop. So doing stuff like this would not cause any unexpected behaviour:

To put it another way, it means that my code was actually equivalent to this (notice how all my variabled are “declared” at the top of the function):

To circumvent this, I created an inline function which would deliver the DOM element with the link. Something like this:

– and from now on, to avoid unnecessary confusion, I will stop declaring my variables anywhere except the beginning of each function.

Lastly, I would like to give some shoutouts to the Mozilla folks for driving us all forward. Firefox 2 actually implements JavaScript 1.7, in which let was introduced as a keyword. let creates a new lexical scope and fixes one or more variables, which will then be promoted to a closure if necessary. Using let, my code would look like this:

– which is a lot simpler than the inline function version I ended up using. However, JavaScript 1.7 is not implemented by other browsers than Firefox 2 and Safari 3.x (according to Wikipedia) so it’s not really an option yet.

Way more nifty: Using compression at field level when persisting #2

In a previous post (here) I showed how the contents of a string property could be internally stored as a GZipped byte array for persistence. The code demonstrated how to achieve this, but not in a particularly pretty manner, because I did some nasty hacks inside the property’s setter and getter – i.e. I crammed all the zipping/unzipping stuff directly inside my domain class.

When using NHibernate for persistence you have another option, which I have recently learned about. So let’s rewrite the example from my previous post.
Read more

Mocking IEnumerable and IEnumerator with NMock2

Edit: This post is actually about a weird NMock error message. As Nigel Thorne so kindly pointed out, this way of testing an IEnumerable is kind of awkward and cumbersome, as I should have just done something like this:

Please use this approach, unless your test subject is actually the implementation of the foreach construct ๐Ÿ˜‰

Original post:
A recent problem I had was when I attempted to mock a function returning an IEnumerable<T>. I went about and punched in somthing that I expected to work – something like this:

– and then I set some expectations on the usage:

– and the usage inside my class under test was something like this:

– but then I ran the test, and I got this cryptic error message:

This was really annoying! Especially due to the fact that the foreach prevented me from seeing what was actually going on. It took me a few minutes to realize that the error came from me being too sloppy to check out the IEnumerator interface I was mocking – the interface looks like this:

(where the generic IEnumerator<T> interface inherits from IEnumerator, narrowing the return type of the Current property down to objects of type T).

Can you spot the error?

The return type of MoveNext is bool!!!

When I am mocking a method call like this:

NMock will check the method signature – and if the signature has a return type other than void, NMock tries to be nice and – instead of emitting an error (which IMO would be appropriate) – returns null! And since null is a reference type, but the expected type was bool, I got the cryptic RemotingException.

The solution was obvious:

PS: I am posting this to avoid having this problem again (for too long). I remember having had this error before, but it took me almost 30 minutes to realize what was wrong. Hopefully, next time I will remember ๐Ÿ™‚

Tailoring a custom matcher for NMock

You’ll often hear proponents of test-driven development claim that unit testing is hard and that it forces them to open up their classes’ hidden logic for them to be testable. That might be true to some degree, but more often in my opinion you’ll find that designing your system to be testable also has the nifty side-effect of separating your logic into .. umm logical chunks… and what I really mean here is that your chunks have a tendency to become orthogonal, which is by far one of the best quality attributes of a system.

BUT that was not what I was going to say, actually – I just wanted to comment on a nifty thing, I recently found out: implementing my own Matcher to use with NMock.

An NMock Matcher is an abstract class, which requires you to implement the following members:

A matcher can be used in the call to With(...) when stubbing or expecting… an example could be setting an expectation that a search function on our user repository will return an empty result… like so:

In the example above, Is is a class containing a static method StringContatining, which returns a matcher of a certain type. Now, when the test runs, and NMock needs to decide if an intercepted function call matches the expectation above, it will iterate though the given matchers, and call their Matches function, passing to it the actual argument as object o.

The matcher returned by StringContaining probably contains an implementation of Matches which looks something like this:

where _substring was probably set in the ctor of the matcher when it was constructed by the StringContaining function.

Now that leads me to my recent problem: I needed to pull out the actual argument given when the expected function call was performed. In my case the argument was a delegate, which I wanted to pull out, and then invoke it a few times with different arguments.

What I did was this:

This allows me to set up an expectation like this:

Now, after the code has been run, I have access to the delegate passed to the file service through snatcher.Object.

If someone knows a cooler way to do this, please do post a comment below. Until then, I will continue to think that it was actually pretty nifty.

How to configure NHaml

Ever wanted to use your own custom HtmlHelper extensions inside your NHaml views? I wanted that, but I got this error:

error CS1061: ‘System.Web.Mvc.HtmlHelper’ does not contain a definition for ‘WhyOhWhy’ and no extension method ‘WhyOhWhy’ accepting a first argument of type ‘System.Web.Mvc.HtmlHelper’ could be found (are you missing a using directive or an assembly reference?)

The problem was that NHaml would not know that there existed some extensions of the HtmlHelper class in some obscure assembly somewhere inside my web app. To do this, you need to tell NHaml exactly which assembly and which namespaces to include in its search. Here is how to do it:

In your web.config, beneath the <configSections> node, add this

– and then outside of <configSections>, add this:

This will cause NHaml.config to be included. We could just have embedded the configuration inside the web.config file, but we want to make separate NHaml.config files for each environment we want to deploy our application in. Then we can turn on NHaml’s compiled view caching feature by flicking the production attribute.

An example NHaml configuration is something like this:

Suddenly you will gain access to everything inside the specified namespaces inside your NHaml templates. Nifty!

Using compression at field level when persisting

One day at work, someone needed to store a lot of text in a field of a domain object – and since we are using NHibernate for persistence, that field would get stored to the database, taking up a huge amount of space.

To circumvent this, we just made the actual type of the member variable description be a byte[], and then we let the accessor property Description zip and unzip when accessing the value.

Like so:

It should be noted that it is crucial that the ToArray() method of the compressed MemoryStream be called after the GZipStream stream has been disposed! That’s because the GZipStream will not write the gzip stream footer bytes until the stream is disposed. So if ToArray() is called before disposing, you will get an incomplete stream of bytes.

Moreover it should be noted that zipping strings in the database is not always cool because:

  1. Compression kicks in for strings at around 2-300 chars. The size of the compressed data is greater than that of the original string for shorter strings.
  2. Querying is impossible/hard/weird. ๐Ÿ™‚

But it is a nifty little trick to put in one’s backpack, and I had all sorts of trouble figuring out exactly how to make the GZipStream behave, so I figured it would be nice to put a working example on the net.

Ruby Fools conference


I have just returned from a week’s worth of Ruby Fools 2008 which by some may also be known as “The Traveling Ruby Circus”. The conference was set to span the 1st and 2nd of April in Copenhagen and the 3rd and 4th of April in Oslo. It was kicked off early with a Hobo tutorial on the 31st of March.

The conference has been great! There’s no other way to describe it. I could go on and on about all the technical stuff I’ve seen, but instead I’ll just show some pictures – because the best thing about the conference has been the really really amazing atmosphere in both our venues (ITU, Copenhagen and Chateau Neuf, Oslo).


Here’s Matz himself talking about “Ruby – past, present, and future” as the opening keynote on the second day in Copenhagen.

Really great to watch this amazing personality talk about a programming language that is so dear to him. Half way through the talk he started telling about the new features of Ruby 1.9, and he got so carried away by the file and string encoding support that it took almost the rest of the talk to get back on track. You can really feel that this man cares about his language.


Here’s Trifork‘s Kresten Krab Thorup on the first day in Oslo in a break, showing off some of his HotRuby* VM method invocation magic to Matz, Michael Fellinger (of Ramaze) and Evan Phoenix (of Rubinius).

Kresten’s HotRuby is an experimental Ruby VM with incredibly fast method invocations. Method invocations seems to be the weak point of this type of dynamic language, but apparently all sorts of tricks can be applied to make invocations faster.


Bekk Consulting‘s Aslak Hellesรธy telling people about a few “underdog web frameworks” on the second day in Oslo.

This room was by far the coolest place to watch presentations! It was really nice to hang out in purple velour sofas, listening to all sorts of interesting stuff. This was also the place for my track on alternative web frameworks.


Here’s Evan Phoenix (to the left, back facing the camera), talking to Wayne Kelly (of the Ruby.NET project, now with IronRuby), along with James Cox (laughing, from Smokeclouds), Dr. Nic (in awe, from various projects, who is by the way a real doctor), Glenn Vanderburg (equally awed, from Relevance), Sam Aaron (seemingly puzzled, from Innovation Factory), and – sitting with his back facing the camera – James Adam (from Reevoo).

This picture really sums up the atmosphere of Chateau Neuf in Oslo, as people were casually sitting around with their laptops. I have to give credit to the entire Ruby community as well, as it seems everybody were just instantly friends with a common interest.

I am really looking forward to next year where we will hopefully arrange another Ruby Fools conference.

(*) Accidental name clash with this – such a shame!

Thoughts on metaprogramming

I’m not too much into long philosophical blog posts, but this is a great post by Raganwald about metaprogramming… Basically, he argues that tools that are powerful are also dangerous – but that should not keep you from using them. As an example he uses metaprogramming, because it is an extremely powerful feature of Ruby which can potentially be used in so many equally beneficial and/ or harmful ways.

Nifty web site with ASP.NET MVC

Sorry about the delay – I was interrupted by the new ASP.NET MVC release CTP 2 which came out last Wednesday or Thursday or something… I am currently working on updating the series to use CTP 2 instead of the first one… please be patient ๐Ÿ™‚

Update: Sorry, but I cancelled this series again. There so many tutorials on how to get going with ASP.NET MVC out there, so I will not finish this series. You should definitely check out Kazi Manzur Rashid’s blog – e.g. his two posts on best practices are brilliant: part 1 & part 2, and he has written a lot of other interesting stuff as well.