Dependency Injection – Good for more than just unit testing.

I read the article on InfoQ about the various blog posts that have been going back forth concerning the pros and cons of Dependency Injection (DI). 

A very interesting read for certain.  I think there are excellent points made on both sides.  Ultimately, there are pluses and minuses to all software architecture decisions.  I believe that if someone doesn’t think that tradeoffs exist in their architecture, they likely do not understand software architecture very well.

Jacob Profit argues that DI has grown in popularity largely because it helps with Test Driven Development (TDD).  Certainly, DI helps dramatically in this area and it likely is a good reason for the popularity surge.  However, I don’t really agree with his assessment of how the caller becomes responsible for configuration of dependencies when implementing DI.  Well, let me restate that to:  It can be that way but it certainly doesn’t have to be and I highly recommend against it.

First, using a framework makes things much easier.  The choice of framework makes a difference.  DI frameworks come in 2 basic flavors:  file based configuration and code based configuration.  A few support both configuration methods but most fall into one category or the other. In the file based configuration camp, is my favorite but there are other excellent choices like Windsor and StructureMap.  ObjectBuilder from the MS Patterns and Practices group is an example of a code based configuration DI framework.

In my opinion, a code based configuration DI framework can lead you down the path the Jacob Profit mentioned – making configuration of dependencies the responsibility of the caller.

Just like Oren, I like DI because it makes it easier to create a loosely coupled software architecture.  When I use, I get the added bonus of the ability to abstract away the location of my components when I use the proxy factories.  With proxy factories, a dependency could be a local, in process, object instance or a proxy to a remoting object, web service, or enterprise service.  The product will soon support WCF as well.  This helps me develop and test in an all local configuration and move to a more distributed model after I am sure the core logic works locally in process.

Eli Lopian entered the discussion on the negative side of DI but made some statements that I think are a little misleading:

When you use DI as a ’Silver Bullet’ you are losing more then half the abilities of your programming language. You can not use static methods or the ‘new‘ keyword or sealed types. Oh, you have to make all your methods virtual too. This is going to be even harder once Extension Methods (and Linq) become main stream.

I will concede the static keyword argument.  It is difficult to handle static methods in DI frameworks.

The new keyword seems to me to be by design rather than a negative side effect.  DI frameworks create and configure dependencies for an object.  Therefore, the need to call new is removed.

It is possible Eli was referring to the need for later dependency creation rather than creating all dependencies at startup.  I can see this being a requirement.  In fact, I have had the requirement myself and I solved it by having the object request the dependency from the context rather than having the dependency injected.  I realize this is not ideal, but no worse than coupling to a concrete implementation or factory in my opinion.

Eli also says that you cannot use sealed types and all methods must be made virtual.  This is where Eli and I start to part ways.

I have used both sealed types in my configuration and have used objects without virtual methods.  In fact, most of my objects do not have virtual methods.  Whether or not to make a class sealed and make methods virtual is a design decision that has nothing to do with the use of a DI container.  I make sure to retain the flexibility of the caller by enforcing the use of the interface/implementation paradigm in my designs.  This way I can divorce my decisions about inheritability from the flexibility I want in the caller’s code.  I agree that you probably want to avoid sealed classes and make methods virtual, if the caller is declaring concrete class variables instead of interfaces.  However, interfaces are the way to go in my opinion.  In fact, using interfaces for variable declaration types is a good idea in many cases even if a DI container is not used at all.

I might be missing the point but the last sentence in the quote from Eli Lopian does not make since to me at all.  Using extension methods is perfectly ok with DI containers.  I have even attached a very simple sample project to this post demonstrating both calling extension methods from an object returned from the context, and calling extension methods on a property injected within the container.  I fail to see why LINQ would be a big issue either.  The types of objects I would be performing LINQ queries on would likely be value objects that I use for my problem domain. These would not be something I would normally configure in a DI container anyway.

By the way, I am already working on a post describing Extension Methods in general and I should be posting that either tomorrow or Monday.

Tags: , , , , ,

More Testing on that Bot’s Vocabulary, Please

Apparently, Microsoft did not perform enough edge case testing on their Santa bot for Windows Live Messenger.  This link points to the story.  It seems Santa is capable of discussing rather naughty topics and using language that is not what you want your kids exposed to.

This just points out how software ends up getting used in ways that the programmers never envision.  By the way, Microsoft has removed the Santa bot and I am certain he will be put through the testing ringer before (if) he makes a future appearance.

Tags: ,

New Property Syntax for C# 3.0

C# 3.0 has many new features that have been widely discussed.  LINQ is likely the most talked about language feature in the new version.  One feature that does not seem to be getting much attention is the new syntax for defining properties.  I have seen this referred to as Anonymous Properties, although I am not sure that this is the official name.

I think this is actually going to be one of my favorite language features going forward and it is certainly long overdue.  Anonymous Properties allows the developer to define a variable and make it available as a property, all in statement.  Traditionally, a class with properties is defined as follows:

public class SampleProperties 
    private string firstName;
    private string lastname;

    public string FirstName
        get {return firstName;}
        set {firstName = value;}

    public string LastName
        get {return lastName;}
        set {lastName = value;}

The above code pattern is recognizable for anyone who has been writing C# at all. Admittedly, it is not a complicated syntax and I much prefer it over the java getter/setter bean pattern. However, Microsoft has added an even more compact syntax for those situations where nothing needs to happen for property getters and setters except the manipulation of the instance variable they wrap:

public class SampleProperties
    public string FirstName {get;set;}
    public string LastName {get;set;}

Much better!

Tags: , , , ,

You’ll Get a Lump of Coal and Like It

In the spirit of the upcoming holiday season, I thought I would create a series of postings on crazy, ridiculous, and downright scary things that have happened to me during my career as a software developer.  Generally, these are the types of things that you can only see if you have spent your career as a consultant.  It just takes that amount of moving around to see so much craziness.  Many of these situations are only funny because so much time has gone by and the pain seems to be forgotten.  These first of these stories is about the lump of coal.

My very first paid programming job was with a huge IT company that shall remain nameless in the post.  Rest assured, you know them but for our purposes we will call it Ubber-IT Company.  My job involved doing everything the experienced members of the team did not want to do.  Things like being on call 24 hours, making sure dataset compression jobs ran (yes, mainframe stuff), and running reports of the TPS variety.

My team was a support team and one of our customer groups was performing a very large, extremely complicated merge of computer systems between two companies that had undergone a corporate merger.  This team of people that I helped support worked absolutely obscene hours for many months.  I heard rumors of failed marriages, health problems, and other undesirable side effects from such a death march.

This project eventually concluded and the day came for the end of project celebration.  Ubber-IT Company was big on giving project trophies.  Everyone who had worked at Ubber for any length of time proudly displayed their project trophies on their cube desk like badges of a war hero and each team member was already clearing space for a new addition.  The VP of Ubber-IT Company came and gave a speech praising the team for their extraordinary level of effort and assured them that they had made a huge profit for Ubber.  Then the trophy boxes were brought out and each team member was announced by name and came forward to receive their badge of honor.

Later, I stopped by the desk of a friend of mine to see what the new trophy was like.  I looked over his trophy collection and could see no new additions.  Just as I had finished looking, he walked up and said, "Oh, are you looking for this?", as he pulled the box out of the garbage can.  He handed me the box and inside was a nice wooden platform with a lump of coal mounted on it.  Along with the coal, came a small piece of paper with a saying that was something to the effect of every diamond starts out as a lump of coal.

I always imagined that the janitors at Ubber-IT Company could not have been happy to carry all of that coal to the dumpster that night.

Tags: ,

« Previous Page