Extensibility through Delegates

One of the key tenets of the SOLID principles used in object oriented design is the Open/Closed Principle. This states that software entities should be open for extension but closed for modification. This rather cryptic statement means that objects shouldn’t have to be changed every time requirements change. Clearly this is not always possible but objects can be made more tolerant to change through OO techniques such as inheritance and polymorphism. This is typically implemented using interfaces or abstract base classes that push responsibility out to concrete classes. Here is an excellent example.

However, this isn’t the only means to achieve this. C# is a rich language which provides multiple, complementary mechanisms to solve similar problems. Through delegates and lambdas, an alternative approach can be used. The following example demonstrates how a class can be extended without modification by allowing the caller to supply their own implementation.

internal class Helper
    internal static string UpdateString(string value)
        return value.ToUpper();
    internal static string UpdateString(Func<string> f)
        return f();

String s = "Hello";
Console.WriteLine(Helper.UpdateString(() => s.ToLower()));



This simple example demonstrates how the Helper class can be offer an extensibility point via a method overload that accepts a delegate (in this case a Func<string>). The caller is able to override the default implementation which converts the string to upper case by providing its own implementation, in the form of a lambda expression.

For more on lambdas and delegates see my previous post on Linq.


The C# Null Coalesce Operator

This post was written partly as a reminder to myself that the C# null coalesce operator exists and can be used effectively to write concise readable code. But what is it?

The Null Coalesce operator in C# is a shorthand way of returning a value but specifying a default if that value is null. This is easily demonstrated using a quick example.

String text = "Hello";
String greeting = text ?? "The greeting was null";

In this case, greeting is assigned the value of text unless text is null. In that case it is given a default value of “The greeting was null”. Clearly this could be achieved by other means such as an if..else statement or a ternary operator, however this method provides a very terse syntax. In addition it deals well with results of direct method calls. For example:

String value = MyFunction() ?? "No value returned";

is much better than

String value2 = MyFunction() != null ? MyFunction() : "No value returned";

and more efficient too as the function is only called once.

It should be noted though that it only deals with nulls and understandably does not handle empty strings. For this the String.IsNullOrEmpty can be used instead.

The Missing Linq

Recently I seem to have been finding more and more old code that would benefit from refactoring using Linq. Whilst still valid, much of the code I see can be significantly improved in terms of clarity and conciseness. Let’s look at a simple example.

The scenario I’ll be using here involves filtering a collection of Person objects to find those with an age lower than 30. First let’s add some boilerplate code as a basis to work with.

class Person
    public int Id { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }

List<Person> people = new List<Person>()
    new Person() { Id = 1, Name = "First Person", Age = 67},
    new Person() { Id = 2, Name = "Second Person", Age = 18},
    new Person() { Id = 3, Name = "Third Person", Age = 42},
    new Person() { Id = 4, Name = "Fourth Person", Age = 8}

private static void PrintListOfPeople(string title, IEnumerable<Person> people)
    foreach (var person in people)
        Console.WriteLine("[{0}] {1}, aged {2}", person.Id, person.Name, person.Age);

Here we have a Person class, a collection of 4 Person instances and a function to display the collection in the console. All pretty straightforward and nothing too exciting. The aim is to take the collection and filter it so that only the people aged under 30 remain.

To do so without Linq one might use the following approach.

// Without Linq
IList<Person> youngPeople = new List<Person>();
foreach (var person in people)
    if (person.Age < 30)
PrintListOfPeople("List without Linq", youngPeople);

This code is pretty simple and it’s probably similar to code you’ve written hundreds of times in the past – initialise a new collection, iterate through the source collection, test each value and if there is a match add it to the new collection. No problems, works very well.

Now consider how the same code could be written using Linq. Note this code requires an Import of the System.Linq namespace.

// With Linq
IEnumerable<Person> youngPeopleLinq = people.Where(p => p.Age < 30);
PrintListOfPeople("List with Linq", youngPeopleLinq);

Wow, we’ve managed to condense 7 lines into 2 and arguably produced code that is more readable. When I first saw the LInq syntax it seemed a bit alien though I think that was more down to the lambda expression than anything else. Let’s dissect this code and see how it works.

Linq Fundamentals

At the high level, Linq really is just a series of extension methods to IEnumerable that offer additional ways to work with collections. In the above example I used the Where extension method. There are many other methods available. So far, so good but what is going on with that crazy lambda expression? To explain, consider the method signature of Where.

The Where extension method takes as a parameter a Func<Person,bool>. For those unfamiliar with Func, this is a language feature which provides a predefined delegate with a particular signature. It just dispenses with the need to define your own delegate. In this case our Func takes a parameter of type Person and returns a bool i.e.

   bool MyFunction(Person p)

So we have the Where extension method which needs to be supplied with a function that accepts a Person object and returns a boolean. The Where method will pass each item in the collection to the function and the boolean returned will indicate if the item being examined should be included or excluded in the resultset. The function itself must apply the test criteria.

We could therefore just create a function which does this test and pass that to the Where method. For example:

IEnumerable<Person> youngPeopleLinq = people.Where(CheckPersonAge);

private static bool CheckPersonAge(Person p)
    return (p.Age < 30);

Whilst this is a perfectly valid approach, the use of a Lambda expression provides a more concise syntax. Let’s look more closely at the lambda used in the original example.

Lambda Expressions 101

A Lambda Expression is a shorthand syntax for an anonymous function. It uses the => operator which translates as “goes into”. So the expression p => p.Age < 30 is translated to “pass p into the expression p.Age < 30”. So p is simply the name of the Person parameter passed into the expression which returns the boolean result of the test p.Age < 30. To summarise, p => p.Age < 30 is equivalent to the CheckPersonAge function shown earlier but with a much more concise syntax.

The lambda syntax confused the heck out of me when I first encountered it. My initial thoughts were “what is ‘p’, it’s not defined anywhere?”  The key thing to remember here is that the compiler is expecting a delegate with a parameter of type Person. All we need to do is provide a name for that parameter so that is can be used inside the target expression.

Linq-ing the Pieces

Hopefully this whirlwind tour of Linq and Lambdas has provided some food for thought. Linq does not really provide anything you could not achieve by other means. However, it does offer a powerful, concise syntax for working with collections. I would encourage any .NET developer to explore the capabilities of Linq and include it as another option in the developer toolbox.

Newlines in a Textbox

I have been implementing some enhancements to an in-house test client application my company uses. It is a Windows Forms application which I wanted to add a textbox to for adding notes to test cases. The Textbox was multi-line and accepts carriage returns. The content of the textbox is then serialized (along with other values) and saved to a file. The file can then be retrieved later, deserialized and used to re-populate the form.

I noticed that whilst the newlines were saved in the file, when re-populating the textbox, the newlines were not displayed and all of the text was on one line. Debugging the app indicated that when reading the file, the newlines were still in place and indicated by \n in the Watch window. After a bit of research, it seems I needed to replace the \n instances with the correct newline characters recognised by C# using the Environment.Newline function. In the end I wrapped this up in a small extension method.

internal static string PreserveFormatting(this string source)
     return source.Replace(((char)10).ToString(), Environment.NewLine);

SignalR and the Enterprise

SignalR seems to be gaining a lot of momentum at the moment. For those unacquainted with it, it describes itself as an “Async signaling library for .NET to help build real-time, multi-user interactive web applications.”  Having taken a brief look at it my initial impressions were that it was most suited to single page web applications like Twitter. However, since reading Kent Weare’s excellent blog posts on using SignalR with BizTalk, I realised there was much more to it. In fact I believe it can fill a gap in the enterprise development space for a simple, lightweight messaging hub.

Kent’s post shows how the SignalR .NET Client library can be used by any .NET project to interact with a SignalR Hub. This was something I had failed to pick up on originally and really extends the hub paradigm to any server side code including BizTalk (as shown in the blog post) but also WCF Services and Azure too. Kent’s example could equally be implemented using MVC deployed as an Azure Web Role in conjunction with a queue and a Worker Role providing the back end. In fact I spent a little time putting together a simple project based upon this as a learning exercise.

Here are some gotchas I encountered with SignalR and how I overcame them.

Where does the Hub URL come from?

In Kent’s example from Part 2 of the blog, the Notifier uses a URL in the connection to the Hub. At first I could not see where this “magic” URL came from. Referring to the SignalR documentation it becomes clear that the Hub is hosted in a web application and the URL refers to the root of that site.

This also explains where the mysterious ../signalr/hubs script originates from.

&lt;script src=&quot;../signalr/hubs&quot;&gt;&lt;/script&gt; 

When I first added this reference into my client page I couldn’t figure out what it pointed at. My project did not include this script so what is it. In fact it is produced by the Hub and browsing to it when the application is running will render the script for you to observe.

Lowercase naming of Hub methods

As part of my solution I implemented a SignalR Hub with a public function named Subscribe. This is used by client side JavaScript to create a subscription to events of interest.


    /// &lt;summary&gt;
    /// Quote Hub that is used to asynchronously notify a client when a quote response is available
    /// &lt;/summary&gt;
    public class QuoteHub : Hub
        public void Subscribe(String quoteId)
            Groups.Add(Context.ConnectionId, quoteId);



However I kept getting the following script error:

Uncaught TypeError: Object #<Object> has no method ‘Subscribe’

After much head scratching I found that the client script needed to use the function name ‘subscribe’ rather than ‘Subscribe’ i.e. no uppercase ‘S’.


Subscription Keys are Strings

My Hub also has a PublishQuoteResults function which is used to publish results of a transaction to clients subscribing to them.

        public void PublishQuoteResults(QuoteResponse quoteResponse)
            // Call the client subscribed to this quote id

I received the following exception…

RuntimeBinderException: The best overloaded method match for ‘SignalR.Hubs.ClientAgent.this[string]’ has some invalid arguments

This turned out to be because the key I was supplying for the Clients object (quoteResponse.QuoteId) was not a string (in fact it was a Guid). Appending ToString() to it resolved this issue.


Use of Uninitialised Connection

The first cut of my client script was as follows:

&lt;script type=&quot;text/javascript&quot;&gt;
    $(function () {
        var hub = $.connection.quoteHub;

        hub.quoteComplete = function(response) {
            $(&quot;#divResponseDetails&quot;).html(&quot;&lt;p&gt;&quot; + response.QuoteId + &quot; has a status of &quot; + response.Status + &quot;&lt;/p&gt;&quot;);



This version failed on the last line (the call to subscribe) with the following error:

Uncaught SignalR: Connection has not been fully initialized. Use .start().done() or .start().fail() to run logic after the connection has started.

This exception message is very helpful and identifies that a continuation should be used to execute the last line after the hub has fully started. The last two lines were adapted as follows and all was well.

            .done(function() { hub.subscribe(&quot;@Model.QuoteId.ToString()&quot;) });

In my view SignalR is a great new addition to the toolbox of the Enterprise developer in a variety of architectures and configurations. I hope my observations help overcome some of the little gotchas that can crop up.

Hello world!

The obligatory test post for any programmer globally. It’s got to be done!