One issue I ran into, however, was that the absolute paths generated under rake resolve to /cygdrive/c/ by default.  This isn’t an issue when calling applications compiled for Cygwin, but they pose a problem if you need to pass an absolute path as a parameter to commands like MSBuild.  One way to resolve this problem is to create an NTFS mount point which mirrors a path that Windows executables can resolve.  Here’s how:

Open up the file /etc/fstab which configures the mount table under Cygwin.  Add a line similar to the following:

C:/projects /projects ntfs binary,posix=0,user 0 0

This mounts the C:/projects folder (where I do all of my project development) as /projects.  Note that the mount point must be named the same as the actual physical NTFS path.  After restarting the shell, the new mount point will be available.  This can be verified by issuing the mount command:

> mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/projects on /projects type ntfs (binary,posix=0,user)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
F: on /cygdrive/f type iso9660 (binary,posix=0,user,noumount,auto)
G: on /cygdrive/g type ntfs (binary,posix=0,user,noumount,auto)
H: on /cygdrive/h type ntfs (binary,posix=0,user,noumount,auto)
I: on /cygdrive/i type vfat (binary,posix=0,user,noumount,auto)

Since Windows accepts the forward slash as a directory delimiter and considers drive letters to be optional, expanding a relative path under the NTFS mount point will render a path that can be correctly interpreted by Windows executables.

While I liked the capabilities of the MvcContrib rules engine overall, there were a few aspects I wanted to change.  One of those things was the coupling to the validation strategy provided by the rules engine and another was the need for a bit of additional infrastructure code to help parse the results when mapping validation errors back to their corresponding UI elements.

I also recently became aware of the Fluent Validation library by Jeremy Skinner and thought to myself: “I wonder how long it would take to just create my own rules engine leveraging the Fluent Validation framework“, so I sat down last weekend to find out. Well, after getting something up and going, I thought I might as well share my results. I should note that given my effort was inspired by the MvcContrib rules engine, some of the same concepts are reflected in my effort (though perhaps with a more naive implementation).

Overview

The basic rules engine works as follows:

1. A user invokes some Controller action.
2. The Controller takes the action’s parameter and invokes the RulesEngine.Process() method.
3. The RulesEngine invokes an injected implementation of IRuleValidator.Validate() on the object.
4. The IRulesValidator returns a RuleValidationResult denoting the status of the validation as well as containing any validation error messages.
5. The RulesEngine uses the Common Service Locator to find implementations of ICommand<T> where T matches the type of the object.
6. The implementations of ICommand<T> are executed and any results accumulated.
7. The RulesEngine returns a ProcessResult which contains the process status and any validation messages and return items.
8. The Controller uses the status to determine which action to display. In the event of a validation failure, the error messages are added to the ModelState with their associated property names.

Here is an example usage:

[HttpPost]
public ActionResult Create(ProductInput productInput)
{
    ProcessResult results = _rulesEngine.Process(productInput);

    if (!results.Successful)
    {
        CopyValidationErrors(results);
        return View(productInput);
    }

    return RedirectToAction("Index");
}

void CopyValidationErrors(ProcessResult results)
{
    foreach (RuleValidationFailure failure in results.ValidationFailures)
    {
        ModelState.AddModelError(failure.PropertyName, failure.Message);
    }
}

In an example application I’ve included with the source, I created an implementation of the IRulesValidator which adapts to the Fluent Validation library:

public class FluentValidationRulesValidator : IRulesValidator
{
    public RuleValidationResult Validate(object message)
    {
        var result = new RuleValidationResult();
        Type validatorType = typeof (AbstractValidator<>).MakeGenericType(message.GetType());
        var validator = (IValidator) ServiceLocator.Current.GetInstance(validatorType);
        ValidationResult validationResult = validator.Validate(message);

        if (!validationResult.IsValid)
        {
            foreach (ValidationFailure error in validationResult.Errors)
            {
                var failure = new RuleValidationFailure(error.ErrorMessage, error.PropertyName);
                result.AddValidationFailure(failure);
            }
        }

        return result;
    }
}

This uses the Common Service Locator to find types closing the Fluent Validation AbstractValidator generic type, validates the message with the validator, and adds any validation error messages to the RuleValidationResult.

Mapping

I also included the ability to map UI types to domain types using a library such as AutoMapper. To express this as an optional feature, I created a MappingRulesEngine which has a dependency on an IMessageMapper. At first I went back and forth between expressing an IMessageMapper as an optional dependency to the RulesEngine, but I don’t really like property injection and the notion of using constructor injection for optional dependencies was a bit distasteful, so using inheritance felt like the cleanest and most expressive option.

The MappingRulesEngine uses the Common Service Locator to find a type closing AssociationConfiguration<T> which provides the type to be converted to as well as configuration used by the MappingRulesEngine to associate validation error messages on the domain type back to the origin properties on the UI type. The following is an example usage:

public class ProductInputAssociationConfiguration : AssociationConfiguration<ProductInput>
{
    public ProductInputAssociationConfiguration()
    {
        ConfigureAssociationsFor<Product>(x =>
            {
                x.For(output => output.Id).Use(input => input.Id);
                x.For(output => output.Description).Use(input => input.Description);
                x.For(output => output.Price).Use(input => input.Price);
            });
    }
}

That’s about it. You can get the source at http://github.com/derekgreer/ncommons.

There may also be a need to easily add new cross-cutting operations across the elements which either aren’t related to the inherent responsibility of each of the elements and/or when no common base object exists allowing inheritance of the new behavior. The Visitor pattern is one approach which aids in facilitating these kinds of needs.

The Visitor Pattern

The Visitor pattern encapsulates common behavior within a single class which is applied to each of the elements of the object structure. The following diagram depicts the pattern structure:

The Visitor pattern is comprised of three main types of participants: the Visitor, the Element, and the Object Structure. The Visitor encapsulates the common behavior needed across different types of elements. Elements are the types within an object structure for which common behavior is needed. The Object Structure is the element container and may take the form of a collection or composite.

Each visitor defines methods specific to each type of element within the object structure while elements define a method capable of accepting a Visitor. When a client desires to apply the visitor behavior to each of the elements, the object structure is used to orchestrate delivery of the visitor to each element. Upon receiving the visitor, each element calls a corresponding method on the visitor, passing a reference to itself as the method parameter. Once invoked, the visitor’s methods are capable of accessing state or invoking behavior specific to each type of element.

The following is an example application which uses the classic Visitor pattern structure to print a parts manifest and a dangerous goods manifest for a thermostat:

class Program
    {
        static void Main(string[] args)
        {
            var thermostat = new Thermostat();
            var partsManifestVisitor = new PartsManifestVisitor();
            var dangerousGoodsManifestVisitor = new DangerousGoodsManifestVisitor();
            thermostat.Accept(partsManifestVisitor);
            thermostat.Accept(dangerousGoodsManifestVisitor);

            Console.WriteLine("Parts List");
            Console.WriteLine("----------");
            partsManifestVisitor.PrintManifest(Console.Out);

            Console.WriteLine("\nDangerous Goods List");
            Console.WriteLine("----------");
            dangerousGoodsManifestVisitor.PrintManifest(Console.Out);

            Console.ReadLine();
        }
    }

    interface IComponentVisitor
    {
        void Visit(Thermostat thermostat);
        void Visit(ThermostatCover thermostatCover);
        void Visit(CircutBoard circutBoard);
        void Visit(MercurySwitch mercurySwitch);
        void Visit(BimetallicStrip bimetallicStrip);
        void Visit(HeatAnticipator heatAnticipator);
    }

    interface IComponentElement
    {
        void Accept(IComponentVisitor visitor);
    }

    class Thermostat : IComponentElement
    {
        readonly IComponentElement[] _elements;

        public Thermostat()
        {
            _elements = new IComponentElement[]
                           {
                                new ThermostatCover(),
                                new CircutBoard(),
                               new MercurySwitch(),
                               new BimetallicStrip(),
                               new HeatAnticipator()
                           };
        }

        public void Accept(IComponentVisitor visitor)
        {
            visitor.Visit(this);

            foreach (var element in _elements)
            {
                element.Accept(visitor);
            }
        }
    }

    class ThermostatCover : IComponentElement
    {
        public void Accept(IComponentVisitor visitor)
        {
            visitor.Visit(this);
        }
    }

    class CircutBoard : IComponentElement
    {
        public void Accept(IComponentVisitor visitor)
        {
            visitor.Visit(this);
        }
    }

    class MercurySwitch : IComponentElement
    {
        public void Accept(IComponentVisitor visitor)
        {
            visitor.Visit(this);
        }
    }

    class BimetallicStrip : IComponentElement
    {
        public void Accept(IComponentVisitor visitor)
        {
            visitor.Visit(this);
        }
    }

    class HeatAnticipator : IComponentElement
    {
        public void Accept(IComponentVisitor visitor)
        {
            visitor.Visit(this);
        }
    }

    class PartsManifestVisitor : IComponentVisitor
    {
        IList<string> manifest = new List<string>();

        public void PrintManifest(TextWriter textWriter)
        {
            manifest.ToList().ForEach(x => textWriter.WriteLine(x));
        }

        public void Visit(Thermostat thermostat)
        {
            manifest.Add("Thermostat");
        }

        public void Visit(ThermostatCover thermostatCover)
        {
            manifest.Add("Thermostat cover");
        }

        public void Visit(CircutBoard circutBoard)
        {
            manifest.Add("Circut board");
        }

        public void Visit(MercurySwitch mercurySwitch)
        {
            manifest.Add("Mercury switch");
        }

        public void Visit(BimetallicStrip bimetallicStrip)
        {
            manifest.Add("Bimetallic strip");
        }

        public void Visit(HeatAnticipator heatAnticipator)
        {
            manifest.Add("Heat anticipator");
        }
    }

    class DangerousGoodsManifestVisitor : IComponentVisitor
    {
        IList<string> manifest = new List<string>();

        public void PrintManifest(TextWriter textWriter)
        {
            manifest.ToList().ForEach(x => textWriter.WriteLine(x));
        }

        public void Visit(Thermostat thermostat)
        {
        }

        public void Visit(ThermostatCover thermostatCover)
        {
        }

        public void Visit(CircutBoard circutBoard)
        {
        }

        public void Visit(MercurySwitch mercurySwitch)
        {
            manifest.Add("Mercury switch");
        }

        public void Visit(BimetallicStrip bimetallicStrip)
        {
        }

        public void Visit(HeatAnticipator heatAnticipator)
        {
        }
    }

Running the application produces the following output:

Parts List
----------
Thermostat
Thermostat cover
Circut board
Mercury switch
Bimetallic strip
Heat anticipator

Dangerous Goods List
----------
Mercury switch

By using the Visitor pattern, the application was able to print a parts list and a dangerous goods list without adding any specific logic to the thermostat components. As new cross-cutting operations come up, a new visitor can be created without modification to the components.

The down side of this example is that if any new components are added, each of the visitors will need to be updated. This violates the Open/Closed principle. Additionally, depending upon the type of behavior encapsulated by the visitor, the behavior for each element type may change for different reasons. In such cases, this would violate the Single Responsibility principle. What would be nice is to achieve a visitor implementation that satisfied both of these concerns.

An Agile Visitor

What if a visitor allowed us to replace the overloaded methods with strategies? Consider the following example:

class Program
    {
        static void Main(string[] args)
        {
            // Declare visitors
            var partsManifestVisitor = new Visitor<IVisitable>();
            var dangerousGoodsManifestVisitor = new Visitor<IVisitable>();

            // Register parts manifest visitor strategies
            partsManifestVisitor.RegisterElementVisitor<Thermostat>(x => Console.WriteLine("Thermostat"));
            partsManifestVisitor.RegisterElementVisitor<ThermostatCover>(x => Console.WriteLine("Thermostat cover"));
            partsManifestVisitor.RegisterElementVisitor<CircutBoard>(x => Console.WriteLine("Circut board"));
            partsManifestVisitor.RegisterElementVisitor<MercurySwitch>(x => Console.WriteLine("Mercury switch"));
            partsManifestVisitor.RegisterElementVisitor<BimetallicStrip>(x => Console.WriteLine("Bimetallic strip"));
            partsManifestVisitor.RegisterElementVisitor<HeatAnticipator>(x => Console.WriteLine("Heat anticipator"));

            // Register dangerous goods manifest visitor strategies
            partsManifestVisitor.RegisterElementVisitor<MercurySwitch>(x => Console.WriteLine("Mercury switch"));

            var thermostat = new Thermostat();

            Console.WriteLine("Parts List");
            Console.WriteLine("----------");
            thermostat.Accept(partsManifestVisitor);

            Console.WriteLine("\nDangerous Goods List");
            Console.WriteLine("----------");
            thermostat.Accept(dangerousGoodsManifestVisitor);

            Console.ReadLine();
        }
    }

In this example, the methods normally found on the classic visitor implementation have been replaced with lambda expressions registered for each type to be visited. There are several advantages to this approach:

First, the Visitor type is extensible and thus adheres to the Open/Closed principle.

Second, the Visitor type is generic, thus enabling it to be used for many (all?) types of visitor implementations.

Third, due to the fact that there are no concrete visitors coupled to a given object structure, new elements can be added to a given object structure without requiring that all visitors for that structure be modified to accommodate the new element.

Forth, the behavior associated with each type is encapsulated in a single Visitor strategy, thus adhering to the single responsibility principle.

Fifth, due to the fact that the Visitor isn’t itself coupled to any particular element type, the element types are likewise not coupled to any object structure specific visitor interface. This allows a given element to participate in unrelated object structure/visitor pattern implementations.

There are a couple of drawbacks to this approach however:

First, what happens when the behavior is more complex? For that, we could just add an overloaded RegisterElementVisitor() to accept an IVisitor:

class ThermostatVisitor : IVisitor<Thermostat>
    {
        public void Visit(Thermostat element)
        {
            Console.WriteLine("Thermostat");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var partsManifestVisitor = new Visitor<IVisitable>();

            partsManifestVisitor.RegisterElementVisitor<Thermostat>(new ThermostatVisitor());

            // snip
        }
    }

That addresses the issue of how we might better encapsulate the more complex behaviors, but a second shortcoming is the loss of encapsulated state. One of the good things the classic Visitor pattern gives us is shared state for accumulating the results of our visitations. There are a few ways we could address this however. The first approach would be to just use closures:

            // snip

            // Register parts manifest visitor strategies
            var partsManifest = new List<string>();

            partsManifestVisitor.RegisterElementVisitor<Thermostat>(x => partsManifest.Add("Thermostat"));
            partsManifestVisitor.RegisterElementVisitor<ThermostatCover>(x => partsManifest.Add("Thermostat cover"));
            partsManifestVisitor.RegisterElementVisitor<CircutBoard>(x => partsManifest.Add("Circut board"));
            partsManifestVisitor.RegisterElementVisitor<MercurySwitch>(x => partsManifest.Add("Mercury switch"));
            partsManifestVisitor.RegisterElementVisitor<BimetallicStrip>(x => partsManifest.Add("Bimetallic strip"));
            partsManifestVisitor.RegisterElementVisitor<HeatAnticipator>(x => partsManifest.Add("Heat anticipator"));

            var thermostat = new Thermostat();
            thermostat.Accept(partsManifestVisitor);

            Console.WriteLine("Parts List");
            Console.WriteLine("----------");
            partsManifest.ToList().ForEach(x => Console.WriteLine(x));

            // snip

A second approach would be to inject a state service when registering IVisitor strategies:

    class Manifest
    {
        public IList<string> Parts { get; private set; }

        public Manifest()
        {
            Parts = new List<string>();
        }

        public void RecordPart(string partName)
        {
            Parts.Add(partName);
        }
    }

    class ThermostatVisitor : IVisitor<Thermostat>
    {
        Manifest _manifest;

        public ThermostatVisitor(Manifest manifest)
        {
            _manifest = manifest;
        }

        public void Visit(Thermostat element)
        {
            _manifest.RecordPart("Thermostat");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            // Declare visitors
            var partsManifestVisitor = new Visitor<IVisitable>();

            // Register parts manifest visitor strategies
            var manifest = new Manifest();
            partsManifestVisitor.RegisterElementVisitor<Thermostat>(new ThermostatVisitor(manifest));

            // other strategies

            var thermostat = new Thermostat();
            thermostat.Accept(partsManifestVisitor);

            Console.WriteLine("Parts List");
            Console.WriteLine("----------");
            manifest.Parts.ToList().ForEach(x => Console.WriteLine(x));
        }
    }

Things are starting to get strewn about though. Let’s bundle all of this up into a facade:

    class PartsManifestVisitorFacade : IVisitor<IVisitable>
    {
        Manifest _manifest = new Manifest();
        Visitor<IVisitable> partsManifestVisitor = new Visitor<IVisitable>();

        public PartsManifestVisitorFacade()
        {
            partsManifestVisitor.RegisterElementVisitor<Thermostat>(new ThermostatVisitor(_manifest));

            // Register other strategies  ...
        }

        public IList<string> Manifest
        {
            get
            {
                return _manifest.Parts;
            }
        }

        public void Visit(IVisitable element)
        {
            partsManifestVisitor.Visit(element);
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var partsManifestVisitor = new PartsManifestVisitorFacade();
            var thermostat = new Thermostat();
            thermostat.Accept(partsManifestVisitor);

            Console.WriteLine("Parts List");
            Console.WriteLine("----------");
            partsManifestVisitor.Manifest.ToList().ForEach(x => Console.WriteLine(x));

            Console.ReadLine();
        }
    }

Alternately, we could use some DI registration magic to have an open generic visitor get closed-over, configured, and injected into wherever we are going to use it. Such an example is a tad bit beyond the intended scope of this article, however, so I’ll leave that as an exercise for the reader to explore.

By this point, you may be wondering: “So where’s the actual Visitor code”? While I’m sure a better implementation is possible, here’s my working prototype:

    /// <summary>
    /// Defines a visitor.
    /// </summary>
    /// <typeparam name="TElement">the type of element to be visited</typeparam>
    interface IVisitor<TElement>
    {
        void Visit(TElement element);
    }

    /// <summary>
    /// Defines a visitable element.
    /// </summary>
    interface IVisitable
    {
        void Accept(IVisitor<IVisitable> visitor);
    }

    /// <summary>
    /// Represents an open/closed visitor.
    /// </summary>
    /// <typeparam name="T">the type of element to visit</typeparam>
    class Visitor<T> : IVisitor<T>
    {
        readonly IDictionary<Type, IVisitorInfo> _visitorInfoDictionary = new Dictionary<Type, IVisitorInfo>();

        /// <summary>
        /// Visits the specified element.
        /// </summary>
        /// <param name="element">element to visit</param>
        public void Visit(T element)
        {
            if (_visitorInfoDictionary.ContainsKey(element.GetType()))
            {
                IVisitorInfo visitorInfo = _visitorInfoDictionary[element.GetType()];
                object visitor = visitorInfo.Visitor;
                IVisitorInvoker invoker = visitorInfo.Invoker;
                invoker.Invoke(visitor, element);
            }
        }

        /// <summary>
        /// Registers an visitor action delegate for a specific type.
        /// </summary>
        /// <typeparam name="TElement">type of element</typeparam>
        /// <param name="action">the visitor action</param>
        public void RegisterElementVisitor<TElement>(Action<TElement> action)
        {
            RegisterElementVisitor(new VisitorAction<TElement>(action));
        }

        /// <summary>
        /// Registers a <see cref="IVisitor{TElement}"/> strategy for a specific type.
        /// </summary>
        /// <typeparam name="TElement">type of element</typeparam>
        /// <param name="visitor">a visitor</param>
        public void RegisterElementVisitor<TElement>(IVisitor<TElement> visitor)
        {
            var visitorInfo = new VisitorInfo<TElement>(
                visitor, new DelegateVisitorInvoker<IVisitor<TElement>, TElement>((x, y) => x.Visit(y)));

            _visitorInfoDictionary.Add(typeof(TElement), visitorInfo);
        }

        /// <summary>
        /// Nested class used to encapsulate a visitor action.
        /// </summary>
        /// <typeparam name="TVisitor">the type of visitor action</typeparam>
        /// <typeparam name="TElement">the type of element</typeparam>
        class DelegateVisitorInvoker<TVisitor, TElement> : IVisitorInvoker
        {
            readonly Action<TVisitor, TElement> _action;

            public DelegateVisitorInvoker(Action<TVisitor, TElement> action)
            {
                _action = action;
            }

            public void Invoke(object action, object instance)
            {
                _action.Invoke((TVisitor)action, (TElement)instance);
            }
        }

        /// <summary>
        /// Nested interface used as the key to the internal dictionary for associating
        /// visitors with their invokers.
        /// </summary>
        interface IVisitorInfo
        {
            IVisitorInvoker Invoker { get; }
            object Visitor { get; }
        }

        /// <summary>
        /// Nested interface used to encapsulate a visit action invocation.
        /// </summary>
        interface IVisitorInvoker
        {
            void Invoke(object action, object instance);
        }

        /// <summary>
        /// Nested class used to encapsulate visitor actions.
        /// </summary>
        /// <typeparam name="TElement">the type of element to visit</typeparam>
        class VisitorAction<TElement> : IVisitor<TElement>
        {
            readonly Action<TElement> _action;

            public VisitorAction(Action<TElement> action)
            {
                _action = action;
            }

            public void Visit(TElement element)
            {
                _action.Invoke(element);
            }
        }

        /// <summary>
        /// Nested class used as the key to the internal dictionary for associating
        /// visitors with their invokers.
        /// </summary>
        /// <typeparam name="TElement">the type of element to be visited</typeparam>
        ///
        /// <remarks>
        /// This type is used as the internal dictionary key to associate visitors with
        /// a corresponding invoker and enables the specific type information to be
        /// maintained for each visitor/element pair.
        /// </remarks>
        class VisitorInfo<TElement> : IVisitorInfo
        {
            public VisitorInfo(IVisitor<TElement> visitor, IVisitorInvoker invoker)
            {
                Visitor = visitor;
                Invoker = invoker;
            }

            public IVisitorInvoker Invoker { get; private set; }
            public object Visitor { get; private set; }
        }
    }

Conclusion

The structure of the classic Visitor pattern seem to reflect the design sensibilities and capabilities of the mainstream programming languages of its day. While the problem it seeks to address remains relevant, it seems prudent to reconsider such patterns from time to time in light of both the ever-evolving capabilities of mainstream development platforms and design principles of today.

So, is this a better approach? Let me know what you think.

What is Double Dispatch?

Technically, Double Dispatch refers to a technique used in the context of a polymorphic method call for mitigating the lack of multimethod support in programming languages. More simply, Double Dispatch is used to invoke an overloaded method where the parameters vary among an inheritance hierarchy. To explain fully, let’s start with a review of polymorphism.

Polymorphism

In the following example, a hierarchy of shapes are defined with each of the derived types overloading a base virtual Draw() method. Next, a console application is used to define a list of each of the shapes and iterate over each shape in the collection calling the Draw() method of each item in the list:

    class Shape
    {
        public virtual void Draw()
        {
            Console.WriteLine("A shape is drawn.");
        }
    }

    class Polygon : Shape
    {
        public override void Draw()
        {
            Console.WriteLine("A polygon is drawn.");
        }
    }

    class Quadrilateral : Polygon
    {
        public override void Draw()
        {
            Console.WriteLine("A quadrilateral is drawn.");
        }
    }

    class Parallelogram : Quadrilateral
    {
        public override void Draw()
        {
            Console.WriteLine("A parallelogram is drawn.");
        }
    }

    class Rectangle : Parallelogram
    {
        public override void Draw()
        {
            Console.WriteLine("A rectangle is drawn.");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var shapes = new List<Shape>
                             {
                                 new Shape(),
                                 new Polygon(),
                                 new Quadrilateral(),
                                 new Parallelogram(),
                                 new Rectangle()
                             };

            foreach (Shape shape in shapes)
            {
                shape.Draw();
            }

            Console.ReadLine();
        }
    }

The following lines are printed to the console upon running the application:

A shape is drawn.
A polygon is drawn.
A quadrilateral is drawn.
A parallelogram is drawn.
A rectangle is drawn.

Note that the proper Draw() method is called for each item in the collection. In most object-oriented languages, this polymorphic behavior is achieved through the use of a virtual table consulted at run-time to derive the proper offset address for an object’s method. This behavior is referred to as “Dynamic Dispatch” or “Single Dispatch”. So, how does this relate to Double Dispatch? To answer this question, let’s next review method overloading.

Method Overloading

In the following example, our Shape class is redefined to have two overloaded Draw methods: one with a parameter of type Surface and one with a parameter of type EtchASketch:

    class Surface
    {
    }

    class EtchASketch : Surface
    {
    }

    class Shape
    {
        public void Draw(Surface surface)
        {
            Console.WriteLine("A shape is drawn on the surface with ink.");
        }

        public void Draw(EtchASketch etchASketch)
        {
            Console.WriteLine("The knobs are moved in attempt to draw the shape.");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var shape = new Shape();
            shape.Draw(new Surface());
            shape.Draw(new EtchASketch());

            Console.ReadLine();
        }
    }

When executed, the following lines are printed to the console:

A shape is drawn on the surface with ink.
The knobs are moved in attempt to draw the shape.

Note that the parameter type determines which Draw() method is invoked.

But what happens if we change the Main() method to the following?

    class Program
    {
        static void Main(string[] args)
        {
            var shape = new Shape();
            Surface surface = new Surface();
            Surface etchASketch = new EtchASketch();

            shape.Draw(surface);
            shape.Draw(etchASketch);

            Console.ReadLine();
        }
    }

Executing this produces the following:

A shape is drawn on the surface with ink.
A shape is drawn on the surface with ink.

What happened? The issue here is that the method to call was determined statically at compile time based upon the reference type, not at run-time based upon the object type. To resolve this issue, another technique is needed … Polymorphic Static Binding.

Polymorphic Static Binding

Polymorphic static binding is a technique where static method invocations are determined at run-time through the use of polymorphism. This can be demonstrated in our example by adding a new Draw(Shape shape) method to the Surface and EtchASketch types which call shape.Draw() with a reference to the current object:

    class Surface
    {
        public virtual void Draw(Shape shape)
        {
            shape.Draw(this);
        }
    }

    class EtchASketch : Surface
    {
        public override void Draw(Shape shape)
        {
            shape.Draw(this);
        }
    }

To invoke the correct Shape.Draw() method, our console application needs to be modified to call the the method indirectly through a Surface reference:

    class Program
    {
        static void Main(string[] args)
        {
            var shape = new Shape();
            Surface surface = new Surface();
            Surface etchASketch = new EtchASketch();

            surface.Draw(shape);
            etchASketch.Draw(shape);

            Console.ReadLine();
        }
    }

Upon executing the application again, the following lines are now printed:

A shape is drawn on the surface with ink.
The knobs are moved in attempt to draw the shape.

This example achieves the desired result by effectively wrapping the static-dispatched method invocation (i.e. Shape.Draw()) within a virtual-dispatch method invocation (i.e. Surface.Draw() and EtchASketch.Draw()). This causes the static Shape.Draw() method invocation to be determined by which virtual Surface.Draw() method invocation is executed.

Although the above example now contains a method invocation using a reference to the current object as the method parameter (often seen with Double Dispatch), it should be noted that Double Dispatch has yet to be demonstrated. Thus far, only one level of virtual dispatching has been used. To demonstrate Double Dispatch, the techniques from both the polymorphism example and the polymorphic static binding example need to be combined as seen in the next section.

Double Dispatch

The following example contains a hierarchy of Surface types and a hierarchy of Shape types. Each Shape type contains an overloaded virtual Draw() method which contains the logic for how the shape is to be drawn on a particular surface. The example console application uses the polymorphic static binding technique to ensure the proper overload is called for each surface type:

    class Surface
    {
        public virtual void Draw(Shape shape)
        {
            shape.Draw(this);
        }
    }

    class EtchASketch : Surface
    {
        public override void Draw(Shape shape)
        {
            shape.Draw(this);
        }
    }

    class Shape
    {
        public virtual void Draw(Surface surface)
        {
            Console.WriteLine("A shape is drawn on the surface with ink.");
        }

        public virtual void Draw(EtchASketch etchASketch)
        {
            Console.WriteLine("The knobs are moved in attempt to draw the shape.");
        }
    }

    class Polygon : Shape
    {
        public override void Draw(Surface surface)
        {
            Console.WriteLine("A polygon is drawn on the surface with ink.");
        }

        public override void Draw(EtchASketch etchASketch)
        {
            Console.WriteLine("The knobs are moved in attempt to draw the polygon.");
        }
    }

    class Quadrilateral : Polygon
    {
        public override void Draw(Surface surface)
        {
            Console.WriteLine("A quadrilateral is drawn on the surface with ink.");
        }

        public override void Draw(EtchASketch etchASketch)
        {
            Console.WriteLine("The knobs are moved in attempt to draw the quadrilateral.");
        }
    }

    class Parallelogram : Quadrilateral
    {
        public override void Draw(Surface surface)
        {
            Console.WriteLine("A parallelogram is drawn on the surface with ink.");
        }

        public override void Draw(EtchASketch etchASketch)
        {
            Console.WriteLine("The knobs are moved in attempt to draw the parallelogram.");
        }
    }

     class Rectangle : Parallelogram
    {
        public override void Draw(Surface surface)
        {
            Console.WriteLine("A rectangle is drawn on the surface with ink.");
        }

        public override void Draw(EtchASketch etchASketch)
        {
            Console.WriteLine("The knobs are moved in attempt to draw the rectangle.");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Surface surface = new Surface();
            Surface etchASketch = new EtchASketch();

            var shapes = new List<Shape>
                             {
                                 new Shape(),
                                 new Polygon(),
                                 new Quadrilateral(),
                                 new Parallelogram(),
                                 new Rectangle()
                             };

            foreach (Shape shape in shapes)
            {
                surface.Draw(shape);
                etchASketch.Draw(shape);
            }

            Console.ReadLine();
        }
    }

Executing this example produces the following:

A shape is drawn on the surface with ink.
The knobs are moved in attempt to draw the shape.
A polygon is drawn on the surface with ink.
The knobs are moved in attempt to draw the polygon.
A quadrilateral is drawn on the surface with ink.
The knobs are moved in attempt to draw the quadrilateral.
A parallelogram is drawn on the surface with ink.
The knobs are moved in attempt to draw the parallelogram.
A rectangle is drawn on the surface with ink.
The knobs are moved in attempt to draw the rectangle.

In the above example, virtual dispatch occurs twice for each call to one of the Surface references: Once when the Surface.Draw() virtual method is called and again when either calls the Shape.Draw() overloaded virtual method. Note again that while the second virtual dispatch is based on the type of Shape instance, the overloaded method called is still determined statically based upon the reference type.

Consequences

So, what’s wrong with Double Dispatch? The problem isn’t so much in the technique, but what design choices might be leading to reliance upon the technique. Consider for instance the hierarchy of shape types in our Double Dispatch example. What happens if we want to add a new surface? In this case, each of the shape types will need to be modified to add knowledge of the new Surface type. This violates the Open/Closed Principle, and in this case in a particularly egregious way (i.e. Its violation is multiplied by the number of shape types we have). Additionally, it violates the Single Responsibility Principle. Changes to how shapes are drawn on a particular surface are likely to differ from surface to surface, thereby leading our shape objects to change for different reasons.

The presence of Double Dispatch generally means that each type in a hierarchy has special handling code within another hierarchy of types. This approach to representing variant behavior leads to code that is less resilient to future changes as well as being more difficult to extend.

The Matrix: Reloaded

Let’s take another stab at modeling our shape/surface intersection matrix. In the following example, several new concepts have been introduced to facilitate decoupling: line segments, points, and brushes:

    interface ISurface
    {
        void Add(LineSegment segment);
    }

    class Paper : ISurface
    {
        readonly IList<LineSegment> _segments = new List<LineSegment>();

        public void Add(LineSegment segment)
        {
            _segments.Add(segment);
        }
    }

    class EtchASketch : ISurface
    {
        readonly IList<LineSegment> _segments = new List<LineSegment>();

        public void Add(LineSegment segment)
        {
            _segments.Add(segment);
        }
    }

    class Point
    {
        public Point(int x, int y)
        {
            X = x;
            Y = y;
        }

        public int X { get; set; }
        public int Y { get; set; }
    }

    class LineSegment
    {
        public LineSegment(Point point1, Point point2)
        {
            Point1 = point1;
            Point2 = point2;
        }

        public Point Point1 { get; set; }
        public Point Point2 { get; set; }
    }

    interface IShape
    {
        IList<LineSegment> GetLineSegments();
    }

    class Polygon : IShape
    {
        public IList<LineSegment> GetLineSegments()
        {
            var segments = new List<LineSegment>();
            segments.Add(new LineSegment(new Point(0, 0), new Point(0, 9)));
            segments.Add(new LineSegment(new Point(0, 9), new Point(3, 6)));
            segments.Add(new LineSegment(new Point(3, 6), new Point(6, 9)));
            segments.Add(new LineSegment(new Point(6, 0), new Point(6, 9)));
            segments.Add(new LineSegment(new Point(6, 0), new Point(3, 3)));
            segments.Add(new LineSegment(new Point(3, 3), new Point(0, 0)));

            return segments;
        }
    }

    class Quadrilateral : IShape
    {
        public IList<LineSegment> GetLineSegments()
        {
            var segments = new List<LineSegment>();
            segments.Add(new LineSegment(new Point(0, 0), new Point(0, 9)));
            segments.Add(new LineSegment(new Point(0, 9), new Point(4, 5)));
            segments.Add(new LineSegment(new Point(4, 0), new Point(0, 4)));
            segments.Add(new LineSegment(new Point(4, 0), new Point(0, 0)));

            return segments;
        }
    }

    class Parallelogram : IShape
    {
        public IList<LineSegment> GetLineSegments()
        {
            var segments = new List<LineSegment>();
            segments.Add(new LineSegment(new Point(0, 4), new Point(0, 9)));
            segments.Add(new LineSegment(new Point(0, 9), new Point(4, 5)));
            segments.Add(new LineSegment(new Point(4, 0), new Point(4, 5)));
            segments.Add(new LineSegment(new Point(4, 0), new Point(0, 4)));

            return segments;
        }
    }

    class Rectangle : IShape
    {
        public IList<LineSegment> GetLineSegments()
        {
            var segments = new List<LineSegment>();
            segments.Add(new LineSegment(new Point(0, 0), new Point(0, 9)));
            segments.Add(new LineSegment(new Point(0, 9), new Point(9, 4)));
            segments.Add(new LineSegment(new Point(4, 0), new Point(9, 4)));
            segments.Add(new LineSegment(new Point(4, 0), new Point(0, 0)));

            return segments;
        }
    }

    class Program
    {
        static readonly IDictionary<Type, IBrush> brushDictionary = new Dictionary<Type, IBrush>();

        static Program()
        {
            brushDictionary.Add(typeof (Paper), new Pencil());
            brushDictionary.Add(typeof (EtchASketch), new EtchASketchKnobs());
        }

        static void Main(string[] args)
        {
            var surfaces = new List<ISurface>
                               {
                                   new Paper(),
                                   new EtchASketch()
                               };

            var shapes = new List<IShape>
                             {
                                 new Polygon(),
                                 new Quadrilateral(),
                                 new Parallelogram(),
                                 new Rectangle()
                             };

            foreach (ISurface surface in surfaces)
                foreach (IShape shape in shapes)
                {
                    Console.WriteLine(string.Format("Drawing a {0} on the {1} ...", shape.GetType().Name,
                                                    surface.GetType().Name));
                    brushDictionary[surface.GetType()].Draw(surface, shape.GetLineSegments());
                    Console.WriteLine(Environment.NewLine);
                }

            Console.ReadLine();
        }
    }

    interface IBrush
    {
        void Draw(ISurface surface, IList<LineSegment> segments);
    }

    class Pencil : IBrush
    {
        public void Draw(ISurface surface, IList<LineSegment> segments)
        {
            foreach (LineSegment segment in segments)
            {
                Console.WriteLine(string.Format("Pencil used to sketch line segment {0},{1} to {2},{3}.",
                                                segment.Point1.X, segment.Point1.Y,
                                                segment.Point2.X, segment.Point2.Y));
            }
        }
    }

    class EtchASketchKnobs : IBrush
    {
        public void Draw(ISurface surface, IList<LineSegment> segments)
        {
            foreach (LineSegment segment in segments)
            {
                Console.WriteLine(string.Format("Knobs used to produce line segment {0},{1} to {2},{3}.",
                                                segment.Point1.X, segment.Point1.Y,
                                                segment.Point2.X, segment.Point2.Y));
            }
        }
    }

Executing this example produces the following:

Drawing a Polygon on the Paper ...
Pencil used to sketch line segment 0,0 to 0,9.
Pencil used to sketch line segment 0,9 to 3,6.
Pencil used to sketch line segment 3,6 to 6,9.
Pencil used to sketch line segment 6,0 to 6,9.
Pencil used to sketch line segment 6,0 to 3,3.
Pencil used to sketch line segment 3,3 to 0,0.

Drawing a Quadrilateral on the Paper ...
Pencil used to sketch line segment 0,0 to 0,9.
Pencil used to sketch line segment 0,9 to 4,5.
Pencil used to sketch line segment 4,0 to 0,4.
Pencil used to sketch line segment 4,0 to 0,0.

Drawing a Parallelogram on the Paper ...
Pencil used to sketch line segment 0,4 to 0,9.
Pencil used to sketch line segment 0,9 to 4,5.
Pencil used to sketch line segment 4,0 to 4,5.
Pencil used to sketch line segment 4,0 to 0,4.

Drawing a Rectangle on the Paper ...
Pencil used to sketch line segment 0,0 to 0,9.
Pencil used to sketch line segment 0,9 to 9,4.
Pencil used to sketch line segment 4,0 to 9,4.
Pencil used to sketch line segment 4,0 to 0,0.

Drawing a Polygon on the EtchASketch ...
Knobs used to produce line segment 0,0 to 0,9.
Knobs used to produce line segment 0,9 to 3,6.
Knobs used to produce line segment 3,6 to 6,9.
Knobs used to produce line segment 6,0 to 6,9.
Knobs used to produce line segment 6,0 to 3,3.
Knobs used to produce line segment 3,3 to 0,0.

Drawing a Quadrilateral on the EtchASketch ...
Knobs used to produce line segment 0,0 to 0,9.
Knobs used to produce line segment 0,9 to 4,5.
Knobs used to produce line segment 4,0 to 0,4.
Knobs used to produce line segment 4,0 to 0,0.

Drawing a Parallelogram on the EtchASketch ...
Knobs used to produce line segment 0,4 to 0,9.
Knobs used to produce line segment 0,9 to 4,5.
Knobs used to produce line segment 4,0 to 4,5.
Knobs used to produce line segment 4,0 to 0,4.

Drawing a Rectangle on the EtchASketch ...
Knobs used to produce line segment 0,0 to 0,9.
Knobs used to produce line segment 0,9 to 9,4.
Knobs used to produce line segment 4,0 to 9,4.
Knobs used to produce line segment 4,0 to 0,0.

By changing the Shape objects to be defined in terms of line segments, knowledge is removed from the shape concerning how to draw itself on any particular surface. Additionally, the Surface type now encapsulates a collection of line segments to simulate the lines being drawn onto the surface. To handle drawing the line segments onto the surfaces, we’ve introduced a Brush type which “draws” the line segments onto a surface in its own peculiar way. To configure which brushes are to be used with which surface, the console application defines a dictionary matching surfaces to brushes.

In contrast to the Double Dispatch example, none of the existing types need to be modified to add new surfaces, shapes, or brushes.

Conclusion

Since Double Dispatch is a technique for calling virtual overloaded methods based upon parameter types which exist within an inheritance hierarchy, its use may be a symptom that the Open/Closed and/or Single responsibility principles are being violated, or that responsibilities may otherwise be misaligned. This is not to say that every case of Double Dispatch means something is amiss, but only that its use should be a flag to reconsider your design in light of future maintenance needs.

Installation

The first step is to obtain the installer from the Cygwin home page. Upon running the installer, you’ll be presented with a wizard which guides you through the installation process:

Upon arriving at the “Select Packages” dialog, you’ll be presented with all the packages available from the selected mirror site(s):

The installer allows you to install selected packages, or install by category:

At the package level, the rotating arrow icon allows you to cycle through the choices of installing one of the package versions available, skipping the package, or in the event the package is already installed, keeping, reinstalling, uninstalling, or obtaining the source code for the package. At the category level, the rotating arrow icon allows you to cycle through the choices of Default, Install, Reinstall, or Uninstall.

It’s best to only select the packages you really think you’ll want to use or immediately explore. There’s quite a bit of applications available and choosing everything would result in quite a large installation time. The installer can always be run at a later time to pickup up additional packages you want to explore.

By default, Cygwin selects the Base category packages as well as a few other odds & ends. Among the packages skipped by default, you may consider also installing the following:

In addition, I personally always install the X11 category packages. While this adds a bit to the download size, it gives you the ability to run your preferred shell (e.g. bash) in an xterm as opposed to the standard terminal window. I’ll cover a bit of X11 installation and customization later in this guide.

When you’re done selecting your packages, click “Next” and the install will begin:

Once complete, click the Finish button and you’re done with the install.

Bash Shell Customization

If you selected the “Add icon to Start Menu” option during the install then you should have a new shortcut entitled “Cygwin Bash Shell” which will start the bash shell as an interactive login shell (i.e. bash –login -i). If not, you can browse to cygwin.bat file located within the chosen installation folder.

When bash runs for the first time, it checks to see if the home directory (denoted in the /etc/passwd file) exists for your account. If not, it creates the directory and copies over some default config files for your shell:

The .bash_profile is used for login shells while the .bashrc file is used for interactive, non-login shells. The default .bash_profile configuration sources the .bashrc file if it exists, so both are sourced for interactive login shells. This effectively allows the .bashrc to serve as the core configuration for both login and non-login shells. The .inputrc file is used to set custom key mappings. Of the three, the .bashrc file will generally be the one you’ll deal with most often.

Go ahead and open up the .bashrc file. (Note: Microsoft Notepad does not display Unix-style line endings correctly. If using a Windows editor, use Wordpad.) After opening the file, you’ll notice that most of the configuration is commented out. The only active configuration are commands to unset the Windows TMP and TEMP variables. You can keep this if you like, but I prefer to keep things a bit more tidy and only have the configuration I actually use. If you want to view the default contents of this file, it can always be viewed from its original source in /etc/skel. The following is a more minimal configuration you might wish to start with:

unset TMP
unset TEMP

PATH=.:~/bin:${PATH}
PATH=${PATH}:c:/Windows/Microsoft.Net/Framework/v3.5/
PATH=${PATH}:c:/Program\  Files/Reflector/
PATH=${PATH}:c:/Program\ Files/Microsoft\  SDKs/Windows/v6.1/Bin/

. ~/.alias
. ~/.functions

In this configuration, several folders have been added to the PATH environment variable. The first places a ~/bin folder before the PATH. This ensures any custom scripts found in the users bin folder occur first in the path allowing commands to be overridden. The remaining three lines are example folders you might want to set if you are doing .Net development related tasks at the bash command line.

The remaining two lines assume the existence of two new files, .alias and .functions. I find storing aliases and functions separately to be a bit more tidy, as well as making it easier to share with others.

Now, let’s take a look at the .bash_profile configuration. By default, the only configuration that exists is the sourcing of the .bashrc file. Again, normally the .bashrc file is only sourced for non-login shells, so this ensures the .bashrc settings are picked up for login shells as well.

In this file, let’s replace the contents with the following:

#  source the system wide bashrc if it exists
if [ -e /etc/bash.bashrc ]  ; then
source /etc/bash.bashrc
fi

# source the users  bashrc if it exists
if [ -e "${HOME}/.bashrc" ] ; then
source  "${HOME}/.bashrc"
fi

PS1='[\h]: ${PWD##*/} > '
set -o vi
export  DISPLAY=127.0.0.1:0.0

In addition to the existing configuration, we’ve added three additional settings. The first customizes how the prompt appears at the command line by setting the PS1 variable. This prompt is a bit plain, but you can spruce it up with a bit of color by replacing it with the following:

PS1=’\[\033]0;\w\007\033[32m\][\h]: \[\033[33m ${PWD##*/}\033[0m\] > ‘

Next, I’ve issued: “set -o vi”. This tells bash to use a vi-style command line editing interface which let’s you more efficiently issue and edit commands at the command line. You can delete this if you don’t ever plan on learning vi.

Next, I’ve set an X environment variable named “DISPLAY” to my localhost. This tells the xterm and other X applications where to attempt to display. You can delete this if you don’t plan on running an xterm, but leaving it certainly won’t hurt.

This should get you started. Your config files will likely evolve from here if you find yourself working at the command line often.

Aliases

The next step you may want to take is to define some command aliases. The bash alias command allows you to set up aliases for verbose or otherwise undesirable commands. As indicated, I store all of my aliases in a .alias file in my home directory to segregate them away from the rest of my .bashrc configuration. Here is a subset of my current list of aliases you might find useful:

alias programfiles="cd  /cygdrive/c/Program\ Files"
alias projects="cd /cygdrive/c/projects"
alias  spikes="cd /cygdrive/c/projects/spikes"
alias vs='cmd /c *.sln'
alias  vs9='/cygdrive/c/Program\ Files/Microsoft\ Visual\ Studio\  9.0/Common7/IDE/devenv.exe *.sln&'
alias  wordpad='/cygdrive/c//Program\ Files/Windows\  NT/Accessories/wordpad.exe'
alias config='cd  /cygdrive/c/Windows/Microsoft.NET/Framework/v2.0.50727/CONFIG'
alias  mydocs='cd /cygdrive/c/Users/${USER}/Documents'
alias myhome='cd  /cygdrive/c/Documents\ and\ Settings/${USER}/'
alias  fusion='fuslogvw.exe'

You’ll be surprised at how fast you’ll start zipping around the system once you’ve got some good navigation aliases in place.

Functions

I don’t tend to write a lot of bash functions, but I’m including this section here for completeness. Like the aliases, I like to segregate any functions I do write away from my main config file to make things a bit cleaner. As an example of what you can do, here is the contents of an example .functions file which allows you to tweet from the command line:

tweet()
{
read -s -p "Password:" password
curl -u  derekgreer:$password -d status="$1"  http://twitter.com/statuses/update.xml
}

Basic Commands

If you’re completely new to the Unix shells, the following are some common commands to get you started with navigating around, creating folders, deleting files, etc.:

Scripts

Once you start getting comfortable with the available commands, you may wish to start writing your own scripts to help with various everyday tasks. While covering the basics of bash shell scripting is beyond the intended scope of this article, you can obtain an archive of some scripts I’ve written for my own purposes from here. Here’s a list of the contained scripts along with a brief description:

X11 – Using an XTerm

The final portion of this guide is intended for those who would like to explore the X Windows system provided by Cygwin. One of the benefits of running an XServer on Windows is the ability to use an XTerm over the standard terminal provided by DOS. XTerm provides more flexibility over the fonts, colors used, and buffers used, provides dynamic resizing, and provides much more intuitive cut-n-paste capabilities (highlight = cut, middle mouse button = paste). It also displays buffered text which comes in handy when you want to use the tail -f command to follow a log file and queue up a bunch of spaces to visually separate new entries.

Assuming you’ve already installed the X11 packages, locate the Cygwin-X folder in your start menu and execute the “XWin Server” shortcut. By default, the XServer starts a plain white terminal:

Since this isn’t likely the style of terminal you’ll want to work with, you can prevent XServer from starting this default xterm by creating an empty .startxwinrc file in your home directory. You can do this by using the touch command:

touch ~/.startxwinrc

Next, you can modify the XTerm shortcut that was created in your start menu’s Cygwin-X folder to start a new xterm with no menu, a custom font, colors, a scrollbar, etc. using the following Target value:

C:\Cygwin\bin\run.exe -p /usr/X11R6/bin xterm -display 127.0.0.1:0.0 -ls -vb -fn 10×20 +tb -bg gray14 -fg ivory -sb -rightbar -sl 400

This command will launch an xterm similar to the following:

From here, you may consider adding the XWin Server shortcut to your startup.

That concludes my guide. Enjoy!

Step 1: Install Cygwin with the cygrunsrv and desired git packages:

Step 2: Create a file named gitd in the /usr/sbin directory with the following content:

#!/bin/bash

git daemon --reuseaddr --base-path=/cygdrive/c/Projects

cygrunsrv   --install gitd                        \
            --path c:/cygwin/bin/bash.exe         \
            --args c:/cygwin/usr/sbin/gitd        \
            --desc "Git Daemon"                   \
            --neverexits                          \
            --shutdown

Step 4: From a bash shell prompt, run the following command to start the service:

cygrunsrv --start gitd

The gitd service should now be running. To verify that everything is setup properly, here is a quick and dirty script which should establish that the desired repositories are remotely accessible:

#!/bin/bash

BASEDIR=/cygdrive/c/Projects
REPO_NAME=testapp$$
REPO_PATH=${BASEDIR}/${REPO_NAME}
REMOTE_PATH=${BASEDIR}/remote$$/

echo "Creating a local git repo ..."
mkdir -p ${REPO_PATH}
cd ${REPO_PATH}
git init
touch .git/git-daemon-export-ok
echo "Commiting test file ..."
touch testfile
git add -A
git commit -m 'Test message'

echo "Simulate remote clone ..."
mkdir ${REMOTE_PATH}
cd ${REMOTE_PATH}
git clone git://localhost/${REPO_NAME}

echo "Cleaning up test folders ..."
rm -rf ${REPO_PATH}
rm -rf ${REMOTE_PATH}

Fortunately, Machine.Specifications (MSpec) extends Resharper to allow for the creation of custom rules which affect only your MSpec types. To create a custom rule for MSpec, follow these steps:

Step 1: Open the Resharper Options Dialog.

Step 2: Navigate to Languages | Naming Style and under “User defined naming rules” click “Add”.

Step 3: This displays the “Edit Extended Naming Rule dialog.  In the “Rule Definition:” text box, give your new rule a name such as “Machine.Specifications Rules”.

Step 4: Within the Affected entities list, un-check Class and scroll to the bottom to locate the entries starting with Machine.Specifications. Select all of these entries.

Step 5: Select all options under Access rights: and leave options under Static/non-static: selected.

Step 6: Add a new naming style to associate this rule to by clicking the Add icon and selecting the desired naming style (e.g. all_lower).

The following diagram shows the dialog after these steps:

After selecting OK, Resharper now ignores the naming warnings for the MSpec types:

“What’s the right number of dependencies to inject? A few. In a very large system, perhaps a few dozen.”

Given that I found this statement to be fairly controversial, I urged the individual to write an article explaining what had brought them to such a conclusion. Later that day, an article was published on the subject explaining their position. After reading the article, it became clear that what was being argued against was the degree of coupling to a dependency injection framework, not dependency injection in general. While minimizing an application’s degree of coupling to any given framework is a goal to be encouraged, the argument was partially based upon a lack of familiarity with the conventional use of dependency injection containers.

In an effort to demonstrate that use of a dependency injection framework is usually unnecessary,the article presents two versions of an example billing application with and without relying upon a framework. The following is a C# version approximating the examples presented within the article:

Dependency Injection Framework Version

    public class Application
    {
        public static void Main()
        {
            IContainer container = new Container().AddConfiguration(BillingConfiguration);
            BillingService billingService = container.Resolve<BillingService>();

            // TODO: do something with the billing service ...
        }
    }

    public class BillingConfiguration : ContainerConfiguration
    {
        protected void Configure()
        {
             Register<ICreditCardService>().As<CreditCardService>();
             Register<ITransactionLog>().As<DatabaseTransactionLog>();
        }
    }

Manual Dependency Injection Version

    public class Application
    {
        public static void Main()
        {
            BillingService billingService = new BillingService(new CreditCardProcessor(), new TransactionLog());

            // TODO: do something with the billing service ...
        }
    }

Comparing the two examples, the second is obviously the more straight forward and concise of the two approaches.

Foreseeing the concern that one might want to use the billing service in a lower layer of the application, the article proceeds to set forth an example which configures a globally accessible static instance of the service within the main method:

    public class Application
    {
        public static void Main()
        {
            BillingService billingService = new BillingService(new CreditCardProcessor(), new TransactionLog());
            BillingService.Instance = billingService;

            // Now the BillingService.Instance can be accessed anywhere within the application
        }
    }

To further address the need to create separate instances of the billing service, the article next presents an example which configures a globally accessible Factory instance which can be accessed from other parts of the application. Perhaps in an attempt to show some recognition of the benefits of using a framework, the Factory is designed to encapsulate the registration and use of a container for retrieving instances of the billing service:

    public class Application
    {
        public static void Main()
        {
            IContainer container = new Container().AddConfiguration(BillingConfiguration);
            BillingService.Factory = new BillingServiceFactory(container);

            // Now we can make new instances of the billing service anywhere within the application
            BillingService billingService = BillingService.Factory.Create();
        }
    }

    public class BillingServiceFactory : ContainerConfiguration
    {
        IContainer _container;

        public BillingServiceFactory(IContainer container)
        {
            _container = container;
        }

        protected void Configure()
        {
             Register<ICreditCardService>().As<CreditCardService>();
             Register<ITransactionLog>().As<DatabaseTransactionLog>();
        }

        public BillingService Create()
        {
            return _container.Resolve<BillingService>() ;
        }
    }

The article concludes by submitting that dependency injection frameworks should only be used for areas of an application that are known extension points, and that in most cases the best course of action is to manually instantiate any needed objects along with their dependencies.

While these examples may seem perfectly sensible to those unfamiliar with using a dependency injection framework, there are several problems with the techniques presented here.

First, the simplicity of these examples fail to highlight the issues involved in real-world applications. Applications designed with an adherence to low-coupling and preferring composition over inheritance often result in object grafts many levels deep. That is to say, the dependencies of one object may have dependencies of their own, which in turn have dependencies of their own, and so forth and so on. While it is possible to use the manual instantiation techniques described in the first example, the resulting code will soon become both unsightly and unwieldy. Couple that with the reuse of components across multiple types and duplication starts to arise. The examples above don’t highlight these issues since they are only working with a simple object graph.

Second, issues arise in the introduction of global variables to access instances of the billing service or the factory. For one, the design becomes more opaque. Classes which reference global resources don’t express their external dependencies through their interface thereby requiring you to look at the code to discover what dependencies are required. Two, this introduces a responsibility to the billing service which isn’t an inherent concern. The responsibility for the creation and lifetime management of the service is a separate concern from the service’s core responsibilities and one which can change for different reasons.

Third, the encapsulation of the container registration and resolution of the billing service within the factory actually serves to more tightly couple the application to the dependency injection framework. What’s been missed in the examples thus far is the fact that the billing service is itself a dependency of other types and they in turn may themselves be dependencies. By ensuring that all types within the system are using dependency injection, the entire dependency chain can be resolved by one call to the container. This eliminates the need to produce specialized factories for each type.

Consider the following example:

    public class Application
    {
        public static void Main()
        {
            new Bootstrapper().Run();
        }
    }

    public class Bootstrapper
    {
        public void Run()
        {
            ConfigureContainer();
            Container.Resolve<IShell>().Show();
        }

        void ConfigureContainer()
        {
            // Configure the container
        }
    }

    public interface IBillingService
    {
        // define billing methods
    }

    public class BillingService : IBillingService
    {
        public BillingService(ICreditCardProcessor creditCardProcessor, ITransactionLog transactionLog) { ... }

        // implement IBillingService methods here
    }

    public interface IShell
    {
         void Show();
    }

    public class Shell : IShell
    {
        public Shell(IBillingService billingService) { ... }

        public void Show() { ... }
    }

In this example the container is only referenced from within the Bootstrapper and the container is only used to resolve an instance of the type IShell. Given that all types have been registered, the container traverses the dependency chain, building up the object graph from the bottom up. This allows the entire application to remain decoupled from the dependency injection framework as well as avoiding the need to create and further maintain type specific factories. As the application grows in complexity, there may be the need to introduce other entry points or strategies for handling lazy-loading, but coupling to the container would remain minimal.

If you find yourself needing to invert your dependencies on an inversion of control framework then you are doing it wrong.

if( ... )
{
    if( ... )
    {
        if( ... )
        {
            if( ... )
            {
                if( ... )
                {
                    //--> do something
                }

            }
        }
    }
}

The structure above becomes increasingly problematic as each additional nested condition adds to the cognitive load required to parse the represented logic. According to studies performed by Noam Chomsky and Gerald Weinberg in 1986, few people can easily understand more than three levels of nested conditional statements. It is therefore recommended that techniques for restructuring the code be sought out when this pattern begins to emerge.

Guard Clauses

One approach to refactoring the arrow anti-pattern is to use guard clauses. Guard clauses are a form of assertion which makes a tangible contribution to the logic of the method. By restructuring nested conditional statements to successive conditional exit points, the code becomes easier to understand and eases further refactoring efforts such as method extraction or clause reordering.

void SomeProcess()
{
    if( ... )
        return;

    if( ... )
        return;

    if( ... )
        return;

    if( ... )
        return;

    if( ... )
        return;

    // do something
}

Method Extraction

Another approach especially suited to blocks comprised of nested looping structures is the extraction of segments into separate methods. For each block forming the body of a loop statement, extract the body into a separate method which can then be examined independently of the containing loop statement:

Before

    void SomeProcess()
    {
        while( ... )
        {
            while( ... )
            {
                while( ... )
                {
                    while( ... )
                    {
                    }
                }
            }
        }
    }

After

    void SomeProcess()
    {
        while( ... )
        {
            MethodA();
        }
    }

    void MethodA()
    {
        while( ... )
        {
            MethodB();
        }
    }

    void MethodB()
    {
        while( ... )
        {
            MethodC();
        }
    }

    void MethodC()
    {
        while( ... )
        {
            MethodD();
        }
    }

Logical And/Or

In cases where the nested structure is comprised solely of checks against the state of an object, the conditions can be extracted into a collection of Boolean methods and combined to form a more concise and readable guard clause:

void SomeProcess()
{
    if(ConditionA() &&
          ConditionB() &&
          ConditionC() &&
          (ConditionD1() || ConditionD2()) &&
          ConditionE())
    {
        // do something
    }
}

Composite Specification Chain

As a variant to the previous technique, the Specification pattern can be used in the form of a composite specification chain to render a concise and readable guard clause. Using this technique, specification classes are written to test each case, and the resulting set of specifications are composed into a single composite specification which can evaluate the state of the given object. Due to the encapsulation of the evaluation logic in the form of separate specification classes, this technique has the added benefit of enabling substitution of the specification implementation via the Strategy pattern for test isolation or other variable composition needs.

void SomeProcess()
{
    ISpecification<SomeType> specification = new IsConditionA()
        .And(new IsConditionB())
        .And(new IsConditionC())
        .And(new IsConditionD1().Or(IsConditionD2()))
        .And(new IsConditionE());

    specification.IsSatisfiedBy(this).Then(() => { /* do something */ });
}

Conclusion

The techniques presented here are a few approaches to helping achieve more readable and maintainable code by eliminating the arrow anti-pattern. Through the judicious application of these techniques, developers can in small ways leave their code base cleaner than they found it.

The pre-built components, or modules, comprising a composite application often share data access concerns such as the need to access a central database. The use of object-relational mapping frameworks are an increasingly common strategy for facilitating data access needs. This is due to their ability to minimize much of the repetitive, low-level data access coding often required by more traditional approaches, and their ability to abstract much of the idiosyncrasies of specific database vendors, providing greater potential for portability between vendors.

NHibernate, arguably the leading object-relational mapping framework for the .Net platform, facilitates object-relational mapping through a centrally configured component called the SessionFactory. A SessionFactory is configured with the connection parameters for a specific database along with the mapping meta-data required for associating objects to the relational data within the database.

It is generally advised that a single SessionFactory be created per database. This is both due to the overhead required in its creation, and in order to facilitate various caching strategies such as the caching of generated SQL statements, and of entities across sessions (referred to as the second-level cache).

For composite applications, configuration of the SessionFactory can pose a bit of an obstacle given that any centralization of the mapping configuration would tend to couple otherwise independent and optional modules together. Additionally, a centralized configuration of the mappings for each of the modules precludes encapsulation of the configuration needs within each module, and can introduce maintenance complexity for modules developed by separate development teams or organizations. On the other hand, allowing modules to maintain their own SessionFactory for a shared database instance introduces startup overhead and precludes taking advantage of the caching features of the framework.

As demonstrated in the remainder of this article, one approach to solving these challenges is to create a staged application bootstrapping process which both facilitates decentralized mapping registration and centralized SessionFactory initialization.

While potentially applicable in other usage scenarios, the following approach is based upon the use of Fluent NHibernate, the Prism composite application library, and the staged bootstrapping strategy presented within the article: Enhancing the Prism Module Initialization Lifecycle.

Our first step in demonstrating this strategy will be to create a module named DataModule which will serve as an infrastructure-only Prism module for configuring NHibernate. Using the ModuleBase implementation of IModule presented in the aforementioned article, the OnPreInitialization() and OnPostInitialization() methods will be overridden.

namespace CompositeSpike.Data.Module
{
    public class DataModule : ModuleBase
    {
        readonly IUnityContainer _container;

        public DataModule(IUnityContainer container)
        {
            _container = container;
        }

        protected override void OnPreInitialization()
        {
        }

        protected override void OnPostInitialization()
        {
        }
    }
}

The OnPreInitialization() method will be used to register services to be consumed by other modules while the OnPostInitialization phase will be used to perform the final database configuration.

Next, let’s create a CustomerModule which represents a module using NHibernate for its data access needs. This module need only override the OnInitialization() method to gain access to services registered during the Pre-Initialization bootstrapping phase.

namespace CompositeSpike.Data.Module
{
    public class CustomerModule : ModuleBase
    {
        readonly IUnityContainer _container;

        public DataModule(IUnityContainer container)
        {
            _container = container;
        }

        protected override void OnInitialization()
        {
        }
    }
}

Next, we’ll define a mapping service to be used by our CustomerModule for registering which map types and/or assemblies are to be included during the configuration of the SessionFactory.

namespace CompositeSpike.Data.Services
{
    public interface IMappingRegistryService
    {
        void AddMap() where T : IClassMap;
        void AddMap(Type classMap);
        void AddMapsFromAssemblyOf();
        void AddMapsFromAssembly(Assembly assembly);
    }
}

Next, we’ll provide an internal implementation of the mapping service to be contained within t
he DataModule. Two additional properties, Assemblies and Types, are provided to enable the DataModule to access any mapping types and assemblies registered by modules during the Initialization phase.

namespace CompositeSpike.Data.Module.Services
{
    class MappingRegistryService : IMappingRegistryService
    {
        readonly IList _assemblies;
        readonly List _types;

        public MappingRegistryService()
        {
            _assemblies = new List();
            _types = new List();
        }

        public IEnumerable Assemblies
        {
            get { return _assemblies; }
        }

        public IEnumerable Types
        {
            get { return _types; }
        }

        public void AddMap() where T : IClassMap
        {
            AddMap(typeof (T));
        }

        public void AddMap(Type type)
        {
            if (type == null)
            {
                throw new ArgumentNullException("type");
            }

            if (!_types.Contains(type))
            {
                _types.Add(type);
            }
        }

        public void AddMapsFromAssemblyOf()
        {
            AddMapsFromAssembly(typeof (T).Assembly);
        }

        public void AddMapsFromAssembly(Assembly assembly)
        {
            if (!_assemblies.Contains(assembly))
            {
                _assemblies.Add(assembly);
            }
        }
    }
}

With the service defined, let’s return to the DataModule and complete the body of the initialization methods.

To ensure the mapping service is available during the initialization phase of the other modules within the application, the IMappingRegistryService and its internal implementation need to be registered as a singleton with the Unity container during the PreInitialization bootstrapping phase:

        protected override void OnPreInitialization()
        {
            _container.RegisterType(new ContainerControlledLifetimeManager());
        }

After modules have been given an opportunity to register mappings with our service during the Initialization phase, the service can be retrieved and used to supply the class map types and/or assemblies required for the Fluent NHibernate configuration:

        protected override void OnPostInitialization()
        {
            var service = _container.Resolve() as MappingRegistryService;

            ISessionFactory sessionFactory = Fluently.Configure()
                .Database(OracleConfiguration.Oracle9
                              .ConnectionString(
                              c => c.Is(ConfigurationManager.ConnectionStrings["example"].ConnectionString))
                              .ShowSql())
                .Mappings(m =>
                    {
                        service.Types.ForEach(t => m.FluentMappings.Add(t));

                        service.Assemblies.ForEach(a => m.FluentMappings.AddFromAssembly(a));
                    })
                .BuildSessionFactory();

            _container
                .RegisterInstance(new NHibernateDatabaseContext(sessionFactory),
                                  new ContainerControlledLifetimeManager());
        }

Our final step is to complete the initialization method within our CustomerModule to register any desired mappings to be used by the DataModule:

        protected override void OnInitialization()
        {
            var dataMappingService = _container.Resolve();
            if (dataMappingService != null) dataMappingService.AddMapsFromAssemblyOf();
        }

That concludes our example.

By utilizing a mapping service in conjunction with a multi-phased initialization strategy, a proper level of separation of concerns can be maintained for the modules within a composite application while at the same time utilizing NHibernate’s SessionFactory in the prescribed manner.