Finding tools that can help you through your daily SCRUM meeting can be a hard task. Other than the usual rubber football that allows a person to speak, nothing else seemed interesting, that is until last week.

I was aimlessly surfing on CodePlex when I found TFS Sticky Buddy. It's a great way for your team to "see" the iteration. It's a small WPF program that visualizes the work items contained in a TFS Team Project.

As soon as I have time, I will try to implement this tool within my teams, because I believe that it is a nice way to focus the team, during the SCRUM meeting, on the iteration.

Yesterday I was helping somebody with a small WCF application and one of the tools I proposed was a plugin visualizer for Visual Studio called WCF Visualizers. It's available freely on CodePlex and will allow you to see different parts of WCF (messages, endpoints, channels...) while you are debugging. Go and check it out, as there are some great images on the project page. The next time I give a WCF presentation with Francois at different user groups, I will also take the time demo this tool.

nVentive was present in Quebec city at HEROES happen {here}, Microsoft's launch for Visual Studio.Net 2008, SQL Server 2008 and Windows Server 2008.

François and I were experts there on the developer side of things, and the one thing we got asked the most, were questions on LINQ.

Everybody knows that LINQ is the hot new way to query objects in C# using a syntax similar to SQL. It depends on 2 tricks, Extension Methods and Lanbda Expressions.

This is a small sample.

public class Blog
{
   public string Title { get; set; }
}
class Program
{
   static void Main(string[] args)
   {
      IList<Blog> blogs = new List<Blog>();
      blogs.Add(new Blog { Title = "3 cheese lasagna" });
      blogs.Add(new Blog { Title = "Blue cheese alfredo sauce" });
      blogs.Add(new Blog { Title = "Macaroni and cheese" });
      blogs.Add(new Blog { Title = "Angel cake" }); 
 
      var blogsWithCheese = from blog in blogs
            where blog.Title.ToLower().Contains("cheese")
            select blog; 
      //blogsWithCheese contains 3 elements.
   }
}

You can query something that is IEnumerable with LINQ to Objects, or a database itself using LINQ to SQL. If XML is your thing, there is a LINQ to XML variant and let's not forget that there is adapter to query Ado.Net DataSets. If you've heard of Entity Framework, LINQ will also work there to abstract it's object SQL language.

Now there's still more, if you have a source that you'd like to query with LINQ, it's just a matter of implementing IQueryProvider and IQueryable.

There are 2 tools I recommend you use in your adventures with LINQ:

1. LINQPad is a interactive LINQ learning tool. Check it out, you'll never go back into Query Analyzer after that.
2. Visual LINQ Query Builder is a plugin for Visual Studio 2008 that will help you develop your queries with a designer, now that's practical.

We've covered a lot so far with Part 1, Part 2, Part 3 and Part 4 of this adventure with extension methods.

Looking back at it, there are some nifty features and side effects that might have been overlooked.

With the magic of generic methods and compiler type inference, we are able to get a pretty discoverable and predictable api.

Let's look at the test first:

What's in there? Well first we see that there is a Reflection() extension point, and this typed extension point has a GetProperty method. This makes it really EASY to figure out what can be done by reflection.

What should the code look like?

Let's start by the extension point class that will scope all available reflection methods:

The ReflectionExtensionPoint class is generic so it can hold the type for which we want to use reflection. So we don't have to instantiate it manually all the time, we can create an extension method that will create such an instance

Here lies all the magic. Since the method is generic and there are no constraints define, we can use the Reflection extension method on anything. Furthermore, there is no need to specify the generic type argument as it is automatically inferred by the compiler

This allows for a pretty compact syntax as shown here:

Now that we have an extension point almost for free that represents a clear and very predictable subset of functionality, we can extend-the-extension-point to add additional behaviors.

Of course, extending the generic ReflectionExtensionPoint class, we need to make our extension methods generic as well so that we can propagate the extended type.

By now, unit tests should turn green, and we should be looking for next bits of business value to provide.

If you haven't read Part 1, Part 2 and Part 3 of this serie, go ahead, we'll wait right here.

In the previous post, we suggested that you can move instance methods that represent overloads to static extension methods.

It's been known for a while that static methods don't do well. They infer with most OO principles and are barely testable. Some will even define those as evil.

Selfishness

When you look at the definition of evil, it is used to indicate acts that are selfish.

Static Methods are selfish in the sense that they keep implementation details for themselves. They take control and keep it. They won't allow you to replace them with a mock version for test purposes. They won't allow their behaviour to be modified without digging into the inner guts and recompiling. They can't be decorated, they can't be proxied, they're selfish.

But can't we have both? The ease and greatness of extension methods without the selfishness and lack of testability of static methods?

Well yes you can... Sort of...

Let's start by looking at an extension method we previously developed:

It contains almost no code but still, it can't be mocked nor replaced.

Make everything an instance again

In order to replace the implementation of this method with another one, we simply need to

1-Extract this method into an interface

2- Provide a default implementation.

3- Make sure the extension method delegates to the instance method

Compromise

On the sunny side, we are now able to completely test our extension method implementation. It can also be mocked as we've extracted an interface. It can be replaced or decorated with a Thread-safe version.

On the dark side, you need to set your mock instance to the public static Extensions field in order for existing code to call the mock. It is sort of an indirect dependency.

Part 1 and Part 2 of this serie presented the basics and design guidelines for developing great extension methods.

Today, we'll try to show how extension methods can be a great tool to lessen the burden of implementing any given interface.

As an example, let's take a look at Unity for a moment.

IUnityContainer is the main interface of Unity. It acts both as a registry of registered type mappings between an abstract type and a concrete type; and as a Service Locator (Dependency Lookup).

What we're used to

Here's a snippet of the RegisterType method with its different overloads:

 public interface IUnityContainer

12 different overloads!!! In total, there are 39 different methods on this interface.

Let's focus on the RegisterType method for a sec. What are the main differences between those overloads?

First and foremost, there's the Generic-strongly-typed version and the loosely-typed version. Then there's the name parameter that allows you to register the same type multiple times with different names. Then there's whether or now you want to specify a lifetimeManager.

If we were to implement that interface and all those RegisterType methods, what would happen? How would we do it? Well, we'd probably chain them all to a single one; the same we do it with chained constructors, right? Which one? The more specific one? Definitely:

 IUnityContainer RegisterType(Type from, Type to, string name, LifetimeManager lifetimeManager);

This is the core method. The one that rules them all. All other overloads are only there to ease usage; at the cost of putting a large burden on the developer. If we want to write an IUnityContainer decorator, we'd have 39 methods to implement... again... and out of those 39 methods, only 3 or 4 would have any valuable logic...

Interfaces on a diet

What if we slim down those interfaces. Let's pretend for one moment that we have a great job at Microsoft, working for the p&p team; and most of all, we get to design Unity! Woohoo!

Since we've been reading the Coach Factor (or are about to), we decide to slim down those pesky interfaces. What would it look like? Well, we already answered this one:

public interface IUnityContainer

{

    //...

    IUnityContainer RegisterType(Type from, Type to, string name, LifetimeManager lifetimeManager);

}

Oh yeah! We just removed 11 methods out of 39. But now what? Will we put the burden on the client of this interface to always call RegisterType with all 4 parameters? Nah...

Extension Methos as Overloads

What if we leveraged our knowledge of extension methods to ease usage of our new slimmed down interface? What would it look like? Exactly! It would exactly look like what we have in the default implementation of the IUnityContainer interface:

Now what?

Well now we can use the full range of overloads and keep IUnityContainer interface as small as possible. It is going to make it a lot easier to mock, decorate and implement the interface without losing any capabilities or ease of use.

Also, we've shared the implementation of overloads throughout all implementations, mocks and decorators of IUnityContainer.

Be careful when designing and trimming down interfaces. It is important that there is no logic associated with the overloads; that is; if registering a component without a name would make a difference and wasn't the equivalent of calling RegisterType(null) then this technique isn't necessarily appropriate.