It’s all about the delivery

Hadi Hariri — Thu, 29 Oct 2009 20:32:37 GMT

The Dependency Inversion Principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

(Source WikiPedia).

Throw that at a terrible programmer, and all you’ll get is a terrible programmer that is annoyed and hates you. So true!

Take the following method:

        public void PrintHelloMessage()

            Console.WriteLine("Hello");

Now ask a developer to add a new method to print the message ‘Goodbye’. Do you think he would do:

        public void PrintGoodbyeMessage()
        {
            Console.WriteLine("Goodbye");
        }

or:

        public void PrintMessage(string message)
        {
            Console.WriteLine(message);
        }

Most likely, he’d do the latter. Why? Because he realizes he’s gaining a benefit by passing a parameter to a method. He knows that if tomorrow you ask him for a “Good Afternoon” message, he won’t have to write a new method.

What is Dependency Injection? It’s one way of complying with the Dependency Inversion Principle. However, when you think about it, what does it boil down to? Passing a parameter to a method, which happens to be a constructor. It seems simple enough doesn’t it? Yet, it’s hard for people to understand it. Why? because they don’t see the value in it.

Explaining a principle to someone without them understanding the benefits and values they get out of it is useless, and that is why concepts such as Dependency Injection or Inversion of Control seem overly complex to the vast majority of developers (believe it or not, those of us that use these things are still a very big minority). It’s complex because they haven’t been explained the values of it. They’ve just been thrown some definition and they are expected to understand that it’s bad for one class to create an instance of another class it uses.

Present a developer with the following code:

    public class AuthServices

        public void AuthUser(string username, string password)

            var authDAL = new AuthDAL();

            var user = authDAL.GetUserByUsername(username);

            if (user != null)

                if ...

and ask them how they’d go about testing this code without having access to a database. Ask them how they’d go about changing AuthDAL for some fake DAL that doesn’t really connect to a database.

They’ll probably come up with the solution of passing the AuthDAL class in as a parameter, and eventually realizing that multiple methods will use the same class, they’ll pass it in via the constructor and set it as an instance field. As long as their AuthDAL has virtual methods, they can create any fake DAL that overrides those methods and returns some dummy value. They might argue that they don’t want virtual methods. And that’s fine. Tell them to define the parameter as an interface. In fact, they probably have already heard of a principle that says that you should program to an interface and not a class. They’ll eventually end up with this code:

  public class AuthServices
    {
        IAuthDAL authDAL;

        public AuthServices(IAuthDAL authDAL)
        {
            _authDAL = authDAL;
        }

        public void AuthUser(string username, string password)
        {
            var user = _authDAL.GetUserByUsername(username);

            if (user != null)
            {
                if ...
            }

        }
    }

And voila! You have Dependency Injection via Constructor.

Once they *get* that, then explain to them other benefits, you know the real benefits they get from doing this: decoupled code, easy maintenance, promotion of SRP, etc. and then throw the principle in their face:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

And they’ll see how it all makes sense.

It’s not about throwing or not throwing books. It’s about showing people how something can help them, how they get value of it.

StructureMap System.InvalidProgramException

Hadi Hariri — Sun, 07 Dec 2008 16:24:21 GMT

I just upgraded to the latest release of StructureMap (2.5) and spent a good portion of time trying to figure out a bug I was having in a complex dependency graph. The original exception is a StructureMap exception, with code 207, which per documentation, you need to look at the inner exception. The problem is that the inner exception isn't awfully helpful:

System.InvalidProgramException : JIT Compiler encountered an internal limitation.

Initially I thought it was related to the WithCtorArg method that allows you to pass in parameters to the constructor, but after stripping everything down to try and come up with a test case, it seems that the issue occurs when you have a class that the container resolves which has a public static property, like so:

1: public interface ISomeClass

2: {

3: void SomeMethod();

4: }

5:

6: public class SomeClass : ISomeClass

7: {

8:

9: public static int SomeProperty { get; set; }

10:

11: public void SomeMethod()

12: {

13: }

14:

15:

16: }

Here's the StructureMap configuration test:

1: [Fact]

2: public void TestStructureMap()

3: {

4: ObjectFactory.Initialize( x => x.ForRequestedType<ISomeClass>().TheDefault.Is.OfConcreteType<SomeClass>());

5:

6: ObjectFactory.GetInstance<ISomeClass>();

7: }

As soon as you make the property private or make it an instance property, the container resolves fine. I tested the same thing with Unity and there doesn't seem to be an issue.

I tested the same code with 2.4.9 and it seems to work.

IoC

It’s all about the delivery

StructureMap System.InvalidProgramException