As a software developer, I've always been fascinated by design patterns and how they can help solve common problems in software design. This holiday season, I've been thinking a lot about how some of these patterns can be incorporated into our daily lives, just like the themes and traditions of Christmas.

One pattern that I've found particularly useful is the "Decorator" pattern. This pattern allows us to add new functionality to an existing object without altering its structure. In the spirit of Christmas, we can think of this pattern as a way to add extra decorations or ornaments to a Christmas tree without changing the tree itself. Just like how we can add various ornaments to a tree to make it more festive and personalized, the Decorator pattern allows us to add new features to an object without changing its core functionality.

Here is an example using C#

// The base component interface
public interface ITree
{
    void Display();
}

// The concrete component classes
public class PineTree : ITree
{
    public void Display()
    {
        Console.WriteLine("I am a pine tree.");
    }
}

public class FirTree : ITree
{
    public void Display()
    {
        Console.WriteLine("I am a fir tree.");
    }
}

// The base decorator class
public abstract class TreeDecorator : ITree
{
    protected ITree tree;

    public TreeDecorator(ITree tree)
    {
        this.tree = tree;
    }

    public virtual void Display()
    {
        tree.Display();
    }
}

// Concrete decorator classes
public class ChristmasLightsDecorator : TreeDecorator
{
    public ChristmasLightsDecorator(ITree tree) : base(tree) {}

    public override void Display()
    {
        base.Display();
        Console.WriteLine("I am decorated with Christmas lights.");
    }
}

public class OrnamentsDecorator : TreeDecorator
{
    public OrnamentsDecorator(ITree tree) : base(tree) {}

    public override void Display()
    {
        base.Display();
        Console.WriteLine("I am decorated with ornaments.");
    }
}

public class GarlandDecorator : TreeDecorator
{
    public GarlandDecorator(ITree tree) : base(tree) {}

    public override void Display()
    {
        base.Display();
        Console.WriteLine("I am decorated with garland.");
    }
}

// Client code
ITree tree = new PineTree();
tree = new ChristmasLightsDecorator(tree);
tree = new OrnamentsDecorator(tree);
tree = new GarlandDecorator(tree);
tree.Display();

I am a pine tree.
I am decorated with Christmas lights.
I am decorated with ornaments.
I am decorated with garland.

This demonstrates how the decorator pattern allows you to dynamically add new behavior to an existing object by wrapping it in decorator objects that implement the same interface. Using an interface to define the base component class allows you to decorate objects of different types, as long as they implement the same interface.

Merry Christmas

A book that inspired my journey Design Patterns Explained 

I recently worked on a project that had a listener service running that took TCP requests and made external calls to a remote WebService. The listener service could have up to 300 concurrent requests.

In testing the service it was showing a significant delay in executing requests above 3-4 concurrent clients. The first bottleneck had to do with the number of allowed HTTP connections to a remote machine from our service. It turns out that by default only 2 concurrent HTTP connections are allowed by default.

Here is an MSDN article that explains the settings that need to be set to allow more connections to be made.

http://msdn.microsoft.com/en-us/library/fb6y0fyc.aspx

So setting something like this what required.

configuration>
  <system.net>
    <connectionManagement>
      <add address = "http://www.contoso.com" maxconnection = "10" />
      <add address = "*" maxconnection = "2" />
    </connectionManagement>
  </system.net>
</configuration>

While this showed a little improvement the problems were not over. It turns out that the ThreadPool by default only starts up with 4 idle threads. As you exceed that limit the ThreadPool checks every 500ms to see if more threads are needed and only spawns up one thread every 500ms. So you can see that it will take a long time to get spawned a large number of concurrent requests.

Solution to this is to set the minimum threads in the threadpool.

ThreadPool.SetMinThreads - http://msdn.microsoft.com/en-us/library/system.threading.threadpool.setminthreads.aspx

So we set the Min to the minimum number of threads we wanted sitting idle. Ok now performance was very good up to the number of threads we set as our minimum. But wait things are not over. We moved the code to another machine and the performance degraged. What could be wrong? It worked on my machine just fine!!

So we looked at what was different about the machines. Turned out my machine was running .NET 2.0 and the other machine was running .NET 2.0 SP1. I guess in .NET 2.0 SP1 a new bug was introduced that if threads are requested to quickly it will revert back to slowly invoking new threads.

Solution is to put a delay after each new call to a delegate for a few milliseconds using something like Thread.Sleep(50);. I had to put about 50ms delay on the machine in question. However I found that this bug was to be fixed in .NET 2.0 SP2. A bit of searching I found that .NET 2.0 SP2 had actually been released but not by itself. You have to download .NET 3.5 SP1 which also includes .NET 2.0 SP2. After installing this on the machine no delay was required any longer and performance was very good.

Hope this helps someone