using System;
using NUnit.Framework;

namespace DependencyInjectionApproaches
{    
    /// <summary>
    /// There are multiple flavors of Dependency Injection - 
    /// 
    /// 1) Constructor injection - dependencies are passed in as constructor parameters
    /// 2) Setter injection - dependencies are passed in to setter methods
    /// 3) Service locator - dependencies are registered with a static gateway which serves up 
    ///     the dependencies (not really dependency *injection* per se, but let's not be sticklers)
    /// 4) PMDI - Poor Man's Dependency Injection (more to come on this one later)
    /// 
    /// I've found that Setter Injection (SI) and Service Locator (SL) have an inherent problem 
    /// because they hide dependencies.  If my class-under-test uses SI or SL, then I often have 
    /// to inspect the source of the class to understand which dependencies must be wired up for 
    /// testing the class.  With Constructor Injection (CI), all of the dependencies are right 
    /// there in the constructor.  There are quite a few other issues related to this matter
    /// which I will discuss below in the context of demonstrating each flavor of dependency 
    /// injection.
    /// 
    /// I've defined an interface "IService" and with multiple implementations.  Each concrete
    /// implementation depends on "ILogger". This dependency is resolved in different ways
    /// for each concrete implementation of IService.
    /// </summary>
    [TestFixture]
    public class DependencyInjectionSpecs
    {
        [Test]
        public void using_constructor_injection()
        {
            var testLogger = new TestLogger(); // Moq would be better, but trying to focus on DI here
            var sut = new ConstructorDependentService(testLogger); 
            
            sut.DoWork();
                        
            testLogger.LastMessage().ShouldEqual("ConstructorDependentService did work");
            
            // (*) when I build the System-Under-Test (sut) see how I can't even call the constructor 
            // without the dependency?  that's good.
            // also notice that I'm only testing my System-Under-Test (SUT) in its interaction with
            // a single dependency.  Good unit tests usually look like this. They only test one class 
            // in its interactions with one abstraction of a dependency.
        }
        
        [Test]
        public void forgetting_to_wire_up_dependency_in_setter()
        {
            var sut = new SetterDependentService();
            
            sut.DoWork(); // throws a NullReferenceException        
            
            // Oops.  I'm able to create my SUT, but I can't execute the DoWork method on it.  Why not?
        }
        
        [Test]
        public void remembering_to_wire_up_dependency_in_setter()
        {
            var testLogger = new TestLogger();            
            var sut = new SetterDependentService();
            sut.Logger = testLogger; // Note this extra requirement for the test to work (*)
            
            sut.DoWork(); 
            
            testLogger.LastMessage().ShouldEqual("SetterDependentService did work");
            
            // (*) That's better than the last test, but more work than the first one.
            // I can still make this test pass, but there's an extra setup cost.  Note that the 
            // dependency is hard to see immediately (we missed it in the previous test).
            // With constructor injection I get a compliation error if I don't set up the dependency.  
            // With setter injection, the missed dependency is not discovered until run time.  Oops.
        }
        
        [Test]
        public void forgetting_to_wire_up_dependency_in_service_locator()
        {
            var sut = new ServiceLocatorDependentService(); // Crud! - KeyNotFoundException (*)
            
            // (*) The test throws immediately due to lack of service registration. Even worse, the 
            // dependency is completely opaque. At least with setter injection I could inspect the 
            // SUT with intellisense, now I'm totally hosed.  I have to look at the implementation 
            // of ServiceLocatorDependentService to figure out how to test it (or if I can at all).
        }
        
        [Test]
        public void remembering_to_wire_up_dependency_in_service_locator()
        {
            var testLogger = new TestLogger();
            ServiceLocator.Configure<ILogger>(() => testLogger); // additional complexity - see below (*)
            var sut = new ServiceLocatorDependentService();
            
            sut.DoWork(); 
            
            testLogger.LastMessage().ShouldEqual("ServiceLocatorDependentService did work");
                        
            // (*)  I'm no longer testing my System-Under-Test in isolation with its dependency, 
            // but I'm also testing my ability to register and resolve dependencies with my Service Locator.
            // This gets worse when my SUT has multiple dependencies which must be resolved from the 
            // Service Locator.
        }        
        
        // PMDI = "Poor Man's Dependency Injection"
        // PMDI may seem like a nice compromise.  You get a default parameterless constructor which uses
        // default implementations of dependencies.  The trouble arises when you want to modify the 
        // constructor of one of *those* dependencies.  What if DefaultLogger changes to require a 
        // constructor parameter? Now changes ripple to all classes that use PMDI with DefaultLogger.
        
        [Test]
        public void PMDI_is_tempting_you()
        {
            var sut = new PoorMansDependencyInjectedService();
            
            sut.DoWork();                
            
            // There is nothing to assert, nothing I can test.  I could visually check my console output, 
            // but doesn't that defeat the whole purpose of an *automated* unit test?
        }
        
        [Test]
        public void PMDI_wants_you_to_come_to_the_dark_side()
        {
            var testLogger = new TestLogger();
            var sut = new PoorMansDependencyInjectedService(testLogger);
            
            sut.DoWork();
                
            testLogger.LastMessage().ShouldEqual("PoorMansDependencyInjectedService did work");

            // yes, it passes.  and with the *same* number of lines as the first example with 
            // constructor injection.  but consider the costs.
            
            // 1) DefaultLogger might change to have constructor arguments (rippling problems, 
            //    but at least caught at compile time)
            // 2) DefaultLogger might change to have setter injected dependencies (now you're 
            //    really hosed! runtime exception!)
            // 3) this is really an SRP violation (Single Responsibility Principle).  Your class 
            //    is not only doing its own job, but is also tasked with determining its appropriate 
            //    defaults.  I suggest you centralize this code in an application bootstrapper and 
            //    find a better way to resolve default implementations (incidendally, StructureMap
            //     has some spectacular abilities in this regard).

            // my last word on PMDI:
            // it seems to me that PMDI is just an attempt to avoid teaching Dependency Injection 
            // to people. I think we're better off showing people all the options and explaining 
            // the pros/cons of each. Perhaps even PMDI has it's place, but it shouldn't just be 
            // the knee-jerk default.  For a shining example of the abuse of PMDI, check out 
            // many of the samples Microsoft released for ASP.NET MVC 1
        }
                    
        #region test support code not relevant to the discussion of dependency injection
        
        [TearDown]
        public void after_each_test_method_executes()
        {
            // make sure we have a clean service locator after each test run.
            // otherwise a registered service from a previous test run can affect
            // the results of other tests, causing false positives or false failures
            // (both really, really bad).
            ServiceLocator.Reset(); 
        }        
        
        #endregion        
    }    
    
    #region more test support code not relevant to the discussion of dependency injection

    public static class SpecificationExtensions
    {
        public static void ShouldEqual(this string actual, string expected)
        {
            Assert.AreEqual(expected, actual);
        }
        
        // check out the NUnit.Specs project for a library of fluent wrappers
        // for NUnit assertions:
        // http://nunitspecs.codeplex.com/
        // I think they are much more clear and concise than the out-of-the-box
        // assertion syntax of NUnit.
    }
    

    #endregion        

    public interface ILogger
    {
        void Log(string message);
    }
    
    public class DefaultLogger : ILogger
    {
        public void Log(string message)
        {
            Console.WriteLine(message);
        }
    }
    
    /// <summary>
    /// Yes!!! - I would much rather use a Mocking framework like Moq, but I
    /// don't want to muddy the waters since the focus here is on learning
    /// dependency injection.  
    /// </summary>
    public class TestLogger : ILogger
    {
        string _lastMessage;
        
        public void Log(string message)
        {
            _lastMessage = message;
        }
        
        public string LastMessage()
        {
            return _lastMessage;
        }
    }
    
    /// <summary>
    /// I hate xml comments, but in this context they just might help you.  :)
    /// </summary>
    public interface IService
    {
        void DoWork();
    }
    
    /// <summary>
    /// Implementation of IService using Constructor Injection
    /// </summary>
    public class ConstructorDependentService : IService
    {
        ILogger _logger;
        
        public ConstructorDependentService(ILogger logger)
        {
            _logger = logger;
        }
        
        public void DoWork()
        {
            _logger.Log("ConstructorDependentService did work");
        }
    }

    /// <summary>
    /// Implementation of IService using Setter Injection
    /// </summary>
    public class SetterDependentService : IService
    {
        ILogger _logger;
        
        public SetterDependentService() { }
        
        public ILogger Logger { internal get { return _logger; } set { _logger = value; } }
        
        public void DoWork()
        {
            _logger.Log("SetterDependentService did work");
        }
    }
    
    /// <summary>
    /// Implementation of IService using Service Locator
    /// </summary>
    public class ServiceLocatorDependentService : IService
    {
        ILogger _logger;
        
        public ServiceLocatorDependentService()
        {        
            _logger = ServiceLocator.GetInstance<ILogger>();
        }        
        
        public void DoWork()
        {
            _logger.Log("ServiceLocatorDependentService did work");
        }
    }
    
    /// <summary>
    /// Bonus! Implementation of IService using Poor Man's Dependency Injection
    /// </summary>
    public class PoorMansDependencyInjectedService : IService
    {
        ILogger _logger;
        
        public PoorMansDependencyInjectedService() : this(new DefaultLogger())    { }
        
        public PoorMansDependencyInjectedService(ILogger logger)
        {
            _logger = logger;
        }
        
        public void DoWork()
        {
            _logger.Log("PoorMansDependencyInjectedService did work");
        }
    }
    
    /// <summary>
    /// NOTE: this is a terrible implementation of a service locator the only purpose of which
    /// is to demonstrate the pitfalls of overreliance on ServiceLocation in your classes.
    /// *IF* you are going to do service location, you're better off using the implementation
    /// from a Dependency Injection framework (like StructureMap's "ObjectFactory").
    /// You might also consider the CommonServiceLocator project:
    /// http://commonservicelocator.codeplex.com/
    /// In general, however, I recommend you steer clear of service locator until you grok
    /// dependency injection enough that you are using constructor injection the majority of 
    /// the time.
    /// </summary>    
    public static class ServiceLocator
    {
        static readonly System.Collections.Generic.Dictionary<Type, Func<object>> Configuration
            = new System.Collections.Generic.Dictionary<Type, Func<object>>();
        
        public static void Configure<TService>(Func<TService> factory)
        {
            Configuration.Add(typeof(TService), () => factory());
        }
        
        public static TService GetInstance<TService>()
        {
            var factory = Configuration[typeof(TService)];
            return (TService)factory();
        }
        
        public static void Reset()
        {
            Configuration.Clear();
        }
    }
}