Antonio Vidal has translated this post into Spanish: you can find it here.

Dependency injection is a very simple concept: if you have an object that interacts with other objects the responsibility of finding a reference to those objects at run time is moved outside of the object itself.

What does it mean for an object to "interact" with other objects? Generally it means invoking methods or reading properties from those objects. So if we have a class A that invokes method Calculate on class B, we can say that A interacts with B.

In the following example we show class A interacting with class B. We can equally say that A depends on class B to fulfill a responsibility. In this case, it not only invokes its method Calculate but it also creates a new instance of that class.

class A
{
  private B _b;

  public A
  {
    _b = new B();
  }

  public int SomeMethod()
  {
    return (_b.Calculate() * 2);
  }
}

In the following example, on the other side, the responsibility of getting a reference to an implementation of a class of type B is moved outside of A:

class A
{
  private B _b;
  public A(B b)
  {
    _b = b;
  }
  public int SomeMethod()
  {
    return _(b.Calculate * 2);
  }
}

In this case we say that a dependency (B) has been injected into A, via the constructor. Of course, you can also inject dependencies via a property (or even a regular method), like in the following example:

class A
{
  private B _b;

  public B B
  {
     get { return _b; }
     set { _b = value; }
  }

  public int SomeMethod()
  {
    if (_b != null)
        return _b.RetrieveValue() * 2;}
    else
        // HANDLE THIS ERROR CASE
        return -1;
  }
}

So this is all there is about dependency injection. Everything else just builds on this core concept.

Like for example Inversion Of Control (IoC) tools which helps you wiring together your objects at run time, injecting all dependencies as needed. So what exactly is Inversion of Control and how does it relate to Dependency Injection (DI)?

I like to associate IoC to the Hollywood Principle: "Don't call us, we'll call you". IoC is a design principle where reusable generic code controls the execution of problem-specific code: it is a characteristic of many frameworks, where the application is built extending or customizing a common skeleton; you put your own classes at specific points and the framework will call you when needed.

You can use an IoC container as a framework to perform Dependency Injection on your behalf: you tell the container which are the concrete implementation classes for your dependencies and the container will make sure that your constructors or setters will be called with the right objects.

Therefore, IoC containers are just a convenience to simplify how dependency injection is handled. But even if you don't use one you could still manually perform dependency injection.

(If you want to have a look at how an IoC container works you can jump to my mini tutorial on Ninject).

Why is the concept of dependency injection important? Because by applying it, you simplify your design (separating the responsibility of using an object from the responsibility of retrieving that object) and your code becomes much easier to test, since you can mock out the dependencies substituting them with fake (stub) objects. But that is the subject for another post.

I thougth I’d just share a couple of Visual Studio C# code snippets to implement disposable classes, based on the well known .NET dispose pattern.

You can download it from here or simply copy and past it from the listing below. Feel free to rename the shortcut to whatever you like

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Base class disposable implementation.</Title>
      <Shortcut>bdisp</Shortcut>
      <Description>
        Code snippet to create a scheleton implementation
        of the IDisposable pattern for a base class.
      </Description>
      <Author>Stefano Ricciardi</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>ClassName</ID>
          <ToolTip>Name of the class.</ToolTip>
          <Default>ClassName</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
        <![CDATA[
    public class $ClassName$: IDisposable
    {
        private bool _disposed = false;

        //Implement IDisposable.
        public void Dispose()
        {
          Dispose(true);
          GC.SuppressFinalize(this);
        }

        protected virtual void Dispose(bool disposing)
        {
          if (!_disposed)
          {
            if (disposing)
            {
              // Free other state (managed objects).
            }
            // Free your own state (unmanaged objects).
            // Set large fields to null.
            _disposed = true;
          }
        }

        // Use C# destructor syntax for finalization code.
        ~$ClassName$()
        {
          // Simply call Dispose(false).
          Dispose(false);
        }
    }            ]]>
      </Code>
    </Snippet>
  </CodeSnippet>
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Base class disposable implementation.</Title>
      <Shortcut>ddisp</Shortcut>
      <Description>
        Code snippet to create a scheleton implementation of the
        IDisposable pattern	for a derived class.
      </Description>
      <Author>Stefano Ricciardi</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>DerivedClassName</ID>
          <ToolTip>Name of the derived class.</ToolTip>
          <Default>Derived</Default>
        </Literal>
        <Literal>
          <ID>BaseClassName</ID>
          <ToolTip>Name of the base class.</ToolTip>
          <Default>Base</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
        <![CDATA[
  public class $DerivedClassName$: $BaseClassName$
  {
      private bool _disposed = false;

      protected override void Dispose(bool disposing)
      {
          if (!_disposed)
          {
              if (disposing)
              {
                  // Release managed resources.
              }
              // Release unmanaged resources.
              // Set large fields to null.
              // Call Dispose on your base class.

              _disposed = true;
          }

          base.Dispose(disposing);
      }
      // The derived class does not have a Finalize method
      // or a Dispose method without parameters because it inherits
      // them from the base class.
  }
]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Go to Part 1

Controlling the Life Cycle of your Objects

In the previous post we did not concern ourselves with the lifecycle of the object returned from Ninject kernel. Ninject provides the following 4 built-in lifecycles (scopes):

1. Transient (default)
2. Singleton (only one instance)
3. Thread (one instance per thread)
4. Request (one instance per web request).

You can create custom scopes if needed.

Singleton:

using (IKernel kernel = new StandardKernel())
{
    kernel.Bind<ITaxCalculator>()
        .To<TaxCalculator>()
        .InSingletonScope()
        .WithConstructorArgument("rate", .2M);

    var tc1 = kernel.Get<ITaxCalculator>();
    var tc2 = kernel.Get<ITaxCalculator>();

    Assert.Same(tc1, tc2);
}

Transient:

using (IKernel kernel = new StandardKernel())
{
    kernel.Bind<ITaxCalculator>()
        .To<TaxCalculator>()
        .InTransientScope()
        .WithConstructorArgument("rate", .2M);

        var tc1 = kernel.Get<ITaxCalculator>();
        var tc2 = kernel.Get<ITaxCalculator>();

        Assert.NotSame(tc1, tc2);
}

More Details on Injection Patterns

With Ninject you can inject:

1. Constructor parameters
2. Properties
3. Methods

Before considering each one in turn, we just need to introduce the [Inject] attribute which may be used to tag constructors, properties and methods requiring injection. Obviously, by tagging constructors, properties or methods, your objects cease to be POCOs.

Constructor Injection

We have already seen an example of constructor injection in Part I when the kernel auto-magically injected an implementation of ITaxCalculator to the Sale Area constructor. In that case, even if we didn't tag the constructor with the [Inject] attribute, the kernel was able to perform the required binding. How?

That was actually a special case: when there is only one constructor available, the tagging is not needed. On the other hand, if there's more than one constructor defined, then then kernel can inject a dependency to only one constructor that needs to have the [Inject] attribute:

public class Sale3
{
    private readonly ITaxCalculator taxCalculator;

    public Sale3() { }

    [Inject]
    public Sale3(ITaxCalculator taxCalculator)
    {
        this.taxCalculator = taxCalculator;
    }

    // other stuff
}

Properties Injection

Instead of passing in the dependencies through the constructor, you can also inject them as properties. Injecting properties is pretty straightforward:

public class Sale2
{
    [Inject]
    public ITaxCalculator TaxCalculator { get; set; } 

    // implicit default constructor and other stuff... 

    public decimal GetTotal()
    {
        decimal total = 0M;
        foreach (var item in lineItems)
        {
            total += TaxCalculator.CalculateTax(item.TotalPrice)
                    + item.TotalPrice;
        } 

        return total;
    }
}

Usage (note that we never explicitely set the TaxCalculator):

using (IKernel kernel = new StandardKernel())
{
    kernel.Bind<ITaxCalculator>()
                  .To<TaxcCalculator>()
                  .WithConstructorArgument("rate", .2M);

    var lineItem1 = new SaleLineItem("Gone with the wind", 10M, 1);
    var lineItem2 = new SaleLineItem("Casablanca", 5M, 2);

    var sale = kernel.Get<Sale2>(); // property injection!
    sale.AddItem(lineItem1);
    sale.AddItem(lineItem2);

    Assert.Equal(24M, sale.GetTotal());
}

There's an important caveat: if you have 2 or more properties injected, the order in which each dependency is injected is not predictable. This might complicate your design, if those dependencies are coupled somehow (e.g. dependency A needs dependency B). For this kind of situations, constructor or method injection is usually preferred.

Methods Injection

Finally, it’s also possible to tag methods for injection. As with constructor parameters, it’s possible to inject more than one value at once.

public class Sale4
{
    private ITaxCalculator taxCalculator;

    // other stuff

    // method injection, will be called by the kernel
    [Inject]
    public void SetTaxCalculator(ITaxCalculator taxCalculator)
    {
        this.taxCalculator = taxCalculator;
    }

    public decimal GetTotal()
    {
        decimal total = 0M;
        foreach (var item in lineItems)
        {
            total += taxCalculator.CalculateTax(item.TotalPrice)
                  + item.TotalPrice;
        }

        return total;
    }
}

Usage (note that we never explicitely call the SetTaxCalculator):

using (IKernel kernel = new StandardKernel())
{
    kernel.Bind<ITaxCalculator>()
          .To<TaxCalculator>()
          .WithConstructorArgument("rate", .2M);

    var lineItem1 = new SaleLineItem("Gone with the wind", 10M, 1);
    var lineItem2 = new SaleLineItem("Casablanca", 5M, 2);

    var sale = kernel.Get<Sale4>(); // method injection!
    sale.AddItem(lineItem1);
    sale.AddItem(lineItem2);

    Assert.Equal(24M, sale.GetTotal());
}

Go to Part 1

What Is Ninject

There are several Inversion of Control (IoC) containers for .NET to pick from (such as Castle Windsor, Structure Map and Microsoft Unity, just to name just a few).  Ninject is one of the newest entries in the arena, but it’s now sufficiently stable at version 2.0.

Ninject tries to focus on “simplicity and ease of use”, removing features that are not deemed necessary (to the point that XML configuration is not offered out-of-the box).

In this and following posts we’ll explore some example of how to use Ninject. I assume that you are somehow familiar with the basic concepts of Inversion of Control and Dependency Injection; if that’s not the case, you should consider having a look at this wikipedia entry (better yet, take some time and read Martin Fowler famous post on the subject).  

Setup

Installing Ninject is quite easy: you simply download the pre-built DLLs it from here. Since Ninject is open source, you can also get the sources from github and build it on your own.

On my Windows machine, I have copied the DLLs on C:\Ninject.

Getting your Feet Wet With Ninject

Once you have Ninject DLLs somewhere on your hard-drive, in order to get started you only need to reference them (typically you only need to reference NInject.dll ). As we said, no XML configuration is required.

Let’s see a few basic examples (the complete source code with unit tests I present in this series are available on github).

"Hello, Ninject”

Suppose we have a fairly simple service to calculate the taxes for a given amount, defined in an ITaxCalculator interface:

decimal CalculateTax(decimal gross);

and a trivial implementation TaxCalculator as follows:

public class TaxCalculator : ITaxCalculator
{
    private readonly decimal _rate;

    public TaxCalculator(decimal rate)
    {
        _rate = rate;
    }

    public decimal CalculateTax(decimal amount)
    {
        return Math.Round(_rate * amount, 2);
    }
}

Now, one or more classes might need to use an ITaxCalculator implementation to fulfill their responsibility (such as calculating the total price for a shopping cart). We can say that an implementation of ITaxCalculator is a dependency to them.

Like many IoC containers, Ninject uses a central object (which it calls the kernel) to provide concrete implementations of dependencies at run-time. The Standard Kernel is the default implementation of such an object. Let's see it in action:

using (IKernel kernel = new StandardKernel())
{
    kernel.Bind<ITaxCalculator>()
          .To<TaxCalculator>()
          .WithConstructorArgument("rate", .2M);

    var tc = kernel.Get<ITaxCalculator>();
    Assert.Equal(20M, tc.CalculateTax(100M));
}

As you can see, through a fluent interface we are instructing the kernel how to bind (resolve) requests for a ITaxCalculator to a TaxCalculator class (a concrete implementation), passing to its constructor a given tax rate (20% in this case).

The example continues showing how a client can retrieve an implementation of the service through the kernel (via the Get() method) and use it.

Some Magic

You might argue that the little example above is far from impressing. So let’s now see Ninject performing something more clever.

Suppose we have a Sale class modeling a ongoing transaction on a ecommerce site. Such a class in our example depends on a ITaxCalculatorto compute the final price of the shopping cart.

public class Sale
{
    private readonly ITaxCalculator taxCalculator;

    public Sale(ITaxCalculator taxCalculator)
    {
        this.taxCalculator = taxCalculator;
    }

    // more stuff....

    public decimal GetTotal()
    {
	// use the tax calculator to calculate the total
    }
}

We might create the sale in the obvious way, based on the preceding example:

kernel.Bind<ITaxCalculator>()
          .To<TaxCalculator>()
          .WithConstructorArgument("rate", .2M);
var sale = new Sale(kernel.Get<ITaxCalculator>());>

More interestingly, it's possible to let Ninject to find out how a Sale should be built based on the binding information it has received:

kernel.Bind<ITaxCalculator>()
          .To<TaxCalculator>()
          .WithConstructorArgument("rate", .2M);
var sale = kernel.Get<Sale>();

Ninject is smart enough to build a Sale class for us taking care of fulfilling the dependencies behind the scenes. This an example of autowiring, a most convenient feature of many IoC containers.

Go to Part 2

This is the third post on a small series about transferring large files with WCF using streaming :

• File Transfer With WCF
• File Transfer With WCF: Part II
• File Transfer With WCF: Part III

I am closing this series of posts by sharing a skeleton for the client side handling of the uploaded and downloaded files. Please note that the following are excerpt from a larger context and so will not compile in your environment as is: they are only intended to give a rough idea of how the files can be handled.

Download

 private void IssueDownloadRequest(string localFile, string serviceUrl, FileDownloadMessage request)
{
    this.service = this.proxy.OpenProxy(serviceUrl);

    try
    {
        using (FileDownloadReturnMessage response = this.service.DownloadFile(request))
        {
            if (response != null && response.FileByteStream != null)
            {
                SaveFile(response.FileByteStream, localFile);
            }
        }

        this.proxy.CloseProxy(this.service);
    }
    catch (Exception e)
    {
        throw new FileTransferProxyException("Error while downloading the file", e);
    }
    finally
    {
        // we expect the stream returned from the server to be closed by the
        // server itself so nothing to be done with it here. Just abort
        // the proxy if needed.
        this.proxy.AbortProxyIfNeeded(this.service);
    }
}

private static void SaveFile(Stream saveFile, string localFilePath)
{
    const int bufferSize = 65536; // 64K

    using (FileStream outfile = new FileStream(localFilePath, FileMode.Create))
    {
        byte[] buffer = new byte[bufferSize];
        int bytesRead = saveFile.Read(buffer, 0, bufferSize);

        while (bytesRead > 0)
        {
            outfile.Write(buffer, 0, bytesRead);
            bytesRead = saveFile.Read(buffer, 0, bufferSize);
        }
    }
}

Upload

public void UploadFile(string localFileName, string serviceUrl, FileTypeEnum fileType)
{
    this.service = this.proxy.OpenProxy(serviceUrl);
    try
    {
        using (Stream fileStream = new FileStream(localFileName, FileMode.Open, FileAccess.Read))
        {
            var request = new FileUploadMessage();
            string remoteFileName = null;
            if (fileType == FileTypeEnum.Generic)
            {
                // we are using the service as a "FTP on WCF"
                // give the remote file the same name as the local one
                remoteFileName = Path.GetFileName(localFileName);
            }

            var fileMetadata = new FileMetaData(localFileName, remoteFileName, fileType);
            request.MetaData = fileMetadata;
            request.FileByteStream = fileStream;

            this.service.UploadFile(request);
            this.proxy.CloseProxy(this.service);
        }
    }
    catch (IOException)
    {
        throw new FileTransferProxyException("Unable to open the file to upload");
    }
    catch (Exception e)
    {
        throw new FileTransferProxyException(e.Message);
    }
    finally
    {
        this.proxy.AbortProxyIfNeeded(this.service);
    }
 }

When it comes to the number of arguments to pass to a function, Uncle Bob is pretty clear. Quoting from Clean Code:

The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided when possible. More than three (polyadic) requires very special justification – and then shouldn’t be used anyway.

Still, some objects might have more than 3 attributes or properties and you usually need some way to initialize them via the constructor. Some attribute might not be mandatory, therefore on some occasions you can get by with a few overloads adding more parameters as needed.

Consider the following (contrieved) example from the world of soccer. I have picked a few attributes that encapsulate the concept of a Team.

namespace Soccer
{
    public enum Color
    {
        White,
        Red,
        Green,
        Blue
    }

    public class Team
    {
        string Name { get; set; }
        string NickName { get; set; }
        Color ShirtColor { get; set; }
        string HomeTown { get; set; }
        string Ground { get; set; }

        public Team(
            string name,
            string nickName,
            Color shirtColor,
            string homeTown,
            string ground)
        {
            Name = name;
            NickName = nickName;
            ShirtColor = shirtColor;
            HomeTown = homeTown;
            Ground = ground;
        }
    }
}

Let’s try initializing one team:

Team team1 = new Team(
    "Manchester United",
    "The Red Devils",
    Color.Red,
    "Manchester",
    "Old Trafford");

In this case we are passing 5 arguments into the constructor. Consider that most of the parameters is a string, therefore it’s quite easy to get confused and invert the order of some parameter (the first two or the last two). The compiler would not be able to help in this case.

What may help here is a builder object with a fluent interface which can help specifying all the attributes of the team. Something like the following:

TeamBuilder tb = new TeamBuilder();
Team team2 =
    tb.CreateTeam("Real Madrid")
        .WithNickName("Los Merengues")
        .WithShirtColor(Color.White)
        .FromTown("Madrid")
        .PlayingAt("Santiago Bernabeu")
        .Build();

Let’s see the code for the TeamBuilder class:

public class TeamBuilder
{
    private string name;
    private string nickName;
    private Color shirtColor;
    private string homeTown;
    private string ground;

    public TeamBuilder CreateTeam(string name)
    {
        this.name = name;
        return this;
    }

    public TeamBuilder WithNickName(string nickName)
    {
        this.nickName = nickName;
        return this;
    }

    public TeamBuilder WithShirtColor(Color shirtColor)
    {
        this.shirtColor = shirtColor;
        return this;
    }

    public TeamBuilder FromTown(string homeTown)
    {
        this.homeTown = homeTown;
        return this;
    }

    public TeamBuilder PlayingAt(string ground)
    {
        this.ground = ground;
        return this;
    }

    public Team Build()
    {
        return new Team(name, nickName, shirtColor, homeTown, ground);
    }
}

The only catch in the solution above is that the caller needs to call Build() at the end of the call chain.

We can improve the solution using an implicit user-defined type conversion operator:

public class TeamBuilder
{
    private string name;
    private string nickName;
    private Color shirtColor;
    private string homeTown;
    private string ground;

    public TeamBuilder CreateTeam(string name)
    {
        this.name = name;
        return this;
    }

    public TeamBuilder WithNickName(string nickName)
    {
        this.nickName = nickName;
        return this;
    }

    public TeamBuilder WithShirtColor(Color shirtColor)
    {
        this.shirtColor = shirtColor;
        return this;
    }

    public TeamBuilder FromTown(string homeTown)
    {
        this.homeTown = homeTown;
        return this;
    }

    public TeamBuilder PlayingAt(string ground)
    {
        this.ground = ground;
        return this;
    }

    // CONVERSION OPERATOR
    public static implicit operator Team(TeamBuilder tb)
    {
        return new Team(
            tb.name,
            tb.nickName,
            tb.shirtColor,
            tb.homeTown,
            tb.ground);
    }

This allows you to create new teams in a more natural way as follows:

TeamBuilder tb = new TeamBuilder();

Team team3 = tb.CreateTeam("Chelsea")
    .WithNickName("The blues")
    .WithShirtColor(Color.Blue)
    .FromTown("London")
    .PlayingAt("Stamford Bridge");

The above solution, albeit quite simple, is a good starting point. To make it ready for real-world code, you should making it more robust with some error checking (what happens if I omit some call from the chain? If I pass an invalid argument? Etc…).

More, you might want to hide the actual implementation from the clients and extract an interface or abstract class from the concrete TeamBuilder. This is left to the reader as an excercise

Floating Points and Rounding Errors.

Working with floating points number can sometimes provide some (un)pleasant surprise, since many real numbers do not have a finite representation and this can lead to rounding errors.

If you need to refresh your knowledge (and have some time to spare), you can find a great treatment in the article What Every Computer Scientist Should Know About Floating-Point Arithmetic:

Squeezing infinitely many real numbers into a finite number of bits requires an approximate representation. Although there are infinitely many integers, in most programs the result of integer computations can be stored in 32 bits. In contrast, given any fixed number of bits, most calculations with real numbers will produce quantities that cannot be exactly represented using that many bits. Therefore the result of a floating-point calculation must often be rounded in order to fit back into its finite representation. This rounding error is the characteristic feature of floating-point computation.

A small example should make the problem clearly visible:

class Program
{
    static void Main(string[] args)
    {
        double a = 22.4;
        double b = a / 131;

        double c = 0;
        for (int i = 0; i < 131; i++)
        {
            c += b;
        }

        Console.WriteLine("Are they equal?: {0}", a == c);
        Console.WriteLine("Difference (a - c) is {0} ", a - c);
    }
}

Here we are taking a double (a), diving it by 131 and then creating a new number (c) by adding the result of that division 131 times. By pure math, a and c should be equal. If you try this small program yourself, this is the output that you would get:

Are they equal?: False
Difference (a - c) is -4,9737991503207E-14

As you can see, the result is not what you might expect, and it's affected by a rounding error that is building up every time b is added to the partial result c.

Note that this is dependent on the number that I have chosen. If you substitute 131 with 5, you will not experience this problem.

Your Own Comparer

Sometimes this behavior might annoy you, especially when you don't need such a high precision and a “rough” equality is all you need. A typical situation is unit testing an algorithm against some expected result: your assertions may fail because of a rounding error, even though the logic of your algorithm is formally correct.

In such a case, you might want to implement your own comparer. A desirable property for such a comparer is a threshold value: if the difference between two floating points is below that threshold they are considered equal.

All you need is to implement the .NET interface IEqualityComparer interface.

class DoubleComparer : IEqualityComparer
{
    private readonly double threshold;

    public DoubleComparer(double threshold)
    {
        this.threshold = threshold;
    }

    public bool Equals(double x, double y)
    {
        return Math.Abs(x - y) < this.threshold;
    }

    public int GetHashCode(double obj)
    {
       return obj.GetHashCode();
    }
}

I have created my own comparer to use in my unit tests. I only have to implement 2 methods: Equals() and GetHashCode().

I don't care much for the actual algorithm of the hashcode implementation, so I am reusing double own algorithm.

Instead, I have applied my own logic to the Equals method: to me, two doubles are equal if the absolute value of their difference is within a given threshold (which I can pass to the comparer in the constructor).

The Comparer In Use

Suppose I have an algorithm to calculate the histogram of a given collection of doubles, and a unit test to validate the calculation against a collection of expected results.

In the example below, samples are the input values which I want to create the histogram for, and expectedBreaks is a sequence containing the left and right limits of the bins of the histogram (in the example I am requiring 5 bins, so the number of breaks is 5 + 1 = 6).

var p = new HistogramProvider();
double[] samples = { 20, 12, 4, 22, 19, 24, 9, 5, -12.2, 13, 0 };
double[] expectedBreaks = { -12.2, -4.96, 2.28, 9.52, 16.76, 24 };

var histogram = p.CreateHistogram(samples, 5);

Assert.IsTrue(expectedBreaks.SequenceEqual(
                       histogram.Breaks,
                       new DoubleComparer(0.01)));

I have figured out the threshold to pass (0.01) based on the relative size of the doubles under analysis. Of course, you should use your own judgement to come up with a sensible threshold according of the range of your input data.

The following is an example of a service containing both generic method calls and generic types.

public interface IContainer<T>
{
    IEnumerable<IProperty<T>> Properties { get; }
}

public interface IPropertyService
{
    IContainer<T> GetProperties<T>(string propertyCode);
}

Now suppose that you don’t know the actual type of the data until runtime (possibly because the type is retrieved from a DB or from some other service). You need a way to interact with these generics, and Reflection can help you here.

Let’s assume that you have managed to get the Type of the data that you are handling (such as string, decimal, double, etc…) and that you have a concrete implementation of the IPropertyService (perhaps through Dependency Injection).

Once you have that, you can invoke the GetProperty method in the following way:

Type type = // ... this is the actual runtime type
IPropertyService service = // ... this is an instance of the service

Type serviceType = typeof(IPropertyService);
MethodInfo getPropertiesInfo =
    serviceType.GetMethod("GetProperties", new Type[] { typeof(string) });

if (getPropertiesInfo == null)
{
    // Uh-oh.... has the interface changed after we wrote this? Throw an exception...
}

Type[] genericArguments = { type }; // we only have one generic argument (<t>)
MethodInfo getPropertiesMethodInfo =
    getPropertiesInfo.MakeGenericMethod(genericArguments);

// Finally invoke the method to search for a price
var propertiesContainer =
    getPropertiesMethodInfo.Invoke(service, new object[] { "price" });

As you can see are quite a few steps to be performed, but at the end, through reflection, you end up with a container filled with all the objects that you have required.

Now assume that you want to access to the single properties contained in the IContainer. You need some way to invoke the C# property Properties. defined on IContainer. Similarly to the MethodInfo class, System.Reflection has a PropertyInfo class that you can use to work with Properties.

The following solution, despite compiling fine, will not work at run-time:

PropertyInfo containerInfo = typeof(IContainer<>).GetProperty("Properties"); // WRONG!!!
if (containerInfo == null)
{
    // the interface has changed. Throw an exception
}

var properties = containerInfo.GetValue(container, null) as IEnumerable;

If you try to run this, you will be greeted by the following exception: Late bound operations cannot be performed on types or methods for which ContainsGenericParameters is true.

After scratching my head for a while, I realized that I should have first created a generic type at run-time before retrieving the PropertyInfo:

Type containerType = typeof(IContainer<>).MakeGenericType(type);
PropertyInfo containerInfo = containerType.GetProperty("Properties");
if (containerInfo == null)
{
    // the interface has changed. Throw an exception
}

var properties = containerInfo.GetValue(container, null) as IEnumerable;

At this point I have a collection of IProperties which I can enumerate through. If needed, since the types in this collection are also generic, I need to repeat the process above until I reach a fundamental type (such as string, double, etc…).

Introduction

Almost 10 years ago now I used to be a Java developer in Motorola. After a long hiatus in the embedded systems and a job change, I have come back to enterprise development, this time in .Net.

I remembered that in the good ol’ days it required 2 steps to see the final rendering of the XML documentation: firing javadoc (usually from within an ANT task) and the open up the content in a browser.

I was quite surprised to see that in the .Net area seeing the final output of the docs was not as straightforward as I hoped for. Yes, there was NDoc to parse the XML, but its development stopped around 2005 and it’s doesn’t support anything beyond C# 2.0. There’s also Sandcastle, but to make it work for me it has required a few downloads and a bit of tweaking here and there. And integrating it into my NAnt task had not been that easy either. But somehow in the end I have pulled that out.

Therefore I have been pleasantly surprised when I met CR Documentor, a little plug-in for visual studio that let’s you see your XML documentation as you write it. It’s almost like having a WYSIWYG editor, without having to launch Sandcastle, wait for the complete build, and open up the browser.

Installation

• Requirements:
  • Visual Studio 2005 or greater (I am pretty confident that you need at least a Professional version as opposed to Express). I am running it on Visual Studio Team System 2008, not sure whether it works also on 2010.
  • The DXCore plugin framework from DevExpress. Possibly the best (and only?) way to get it is to get through the excellent free CodeRush Xpress for C# and VB
• Download the plugin: CR Documentor is hosted at Google Code at this link.
• Copy the dll in your DX-Core plugin-folder (C:\Users\<username>\Documents\DevExpress\IDE Tools\Community\PlugIns)
• Restart Visual Studio

Usage

1. CR Documentor adds itself in the right click menu, close to the bottom. From the submenu, choose “Show CR_Documentor window”.
2. A new window opens up in floating mode (I prefer to dock-it to the right side together with my solution explorer and luckily the plug-in remembers this choice every time I open the window after closing it and at startup).
3. Now every time your cursor is on an XML doc, you can see the preview in the Documentor window. See for example when I put the cursor on the XML doc of a class: I get a complete picture of the documentation for that class and its methods all in real time.
   
4. There are a few other features that I don’t use very often. All of them are accessible by the right-click content sensitive menu:
   • Expand/Collapse all XML comments in the editor
   • Insert XML docs templates (I prefer to use GhostDoc for that).

Configuration

Like all DXCore plugins, you can access to the configuration by pressing ALT+CTRL+SHIFT+O combination. I like to check all my options to Sandcastle because that’s the tool that I will be using to create the final XML documentation.

This is the third post of a series on the Service Locator pattern. In the first post I described how to create a basic service locator for your C# application, while in the second post I introduced lazy initialization of the services.

We now add another piece to our puzzle, transforming the Service Locator class into a singleton.

The Singleton Pattern

The singleton is arguably the most known and controversial design pattern. Some say singletons are good, some says singletons are evil. Eric Gamma himself (one of the Gang Of Four) in a recent interview stated that (emphasis added):

When discussing which patterns to drop, we found that we still love them all. (Not really—I’m in favor of dropping Singleton. Its use is almost always a design smell.)

I don’t have a strong opinion either way; I tend to use it sparingly and in the following code I will show how to apply this pattern to the service locator. There are already countless blogs discussing the pros and the cons of the singleton pattern, therefore I won’t discuss about it any further.

The Singleton Service Locator

The following was our initial implementation (other details of the classes have been removed for clarity). The constructor was internal, allowing all potential clients from within the assembly to invoke it. Clients could either pass around a reference to the created service locator, or instantiate new instances each time:

internal class ServiceLocator : IServiceLocator
{
    // a map between contracts -> concrete implementation classes
    private IDictionary<Type, Type> servicesType;

    // a map containing references to concrete implementation already instantiated
    // (the service locator uses lazy instantiation).
    private IDictionary<Type, object> instantiatedServices;

    internal ServiceLocator()
    {
        this.servicesType = new Dictionary<Type, Type>();
        this.instantiatedServices = new Dictionary<Type, object>();

        this.BuildServiceTypesMap();
    }

    // rest of the methods
 }

To implement the singleton pattern, we make the constructor private and provide clients with a static method through which we can retrieve an instance of the service.

Note how the creation of the single instance of the ServiceLocator class is itself lazy and thread safe. There are a few variations on the theme when it comes to singleton thread safe initialization (see for example this post by Jon Skeet).

internal class ServiceLocator : IServiceLocator
{
        // a map between contracts -> concrete implementation classes
        private IDictionary<Type, Type> servicesType;
        private static readonly object TheLock = new Object();

        private static IServiceLocator instance;

        // a map containing references to concrete implementation already instantiated
        // (the service locator uses lazy instantiation).
        private readonly IDictionary<Type, object> instantiatedServices;

        private ServiceLocator()
        {
            this.servicesType = new Dictionary<Type, Type>();
            this.instantiatedServices = new Dictionary<Type, object>();

            this.BuildServiceTypesMap();
        }

        public static IServiceLocator Instance
        {
            get
            {
                lock (TheLock) // thread safety
                {
                    if (instance == null)
                    {
                        instance = new ServiceLocator();
                    }
                }

                return instance;
            }
        }

        // rest of the methods
 }

Clients will now simply invoke the GetService() method through the singleton instance, without having to create a new object each time:

IServiceA service = ServiceLocator.Instance.GetService<IUniverseFileServiceAdapter>();