Dependency Injection

I have released an early version of a Dependency injection framework I am developing. Yes another one!

NDependencyInjection is being used in a real application and is under heavy development. I intend it to be very opinionated. It will make writing apps the way I write them easy.

First decision: Only support constructor injection.


This decision is not without it's complications. Not least of which is 'what do you do about objects that refer to each-other?'. Luckly I have a solution to this problem. The injection framework in-fact automatically solves these loops.

Second decision: Applications should be built in layers.


When assembling the complex network of simple objects that make up a good design. You group them into sub-assemblies and these into bigger assemblies until you have your final application.

Within the Application there are objects that you only have one instance of. These are by definition Singletons.

Within the sub-assemblies you get classes that act as Singletons, but only within that scope. You may have several instances in your application, but the individual sub-system only has one, and all references to that type refer to the same instance. In all respects this is a ScopedSingleton.

The framework supports Scopes and Singletons.
More on this later.

Anyway.. for now.. you can get at an early release version from NDependencyInjection.

Prefactoring

I have found it valuable to distinguish between the refactoring done in Red-Green-Refactor and the Refactoring done when I have a new story to implement and the design needs to change to accommodate the new feature.

This second form I call Prefactoring.

Prefactoring is performed on otherwise clean well factored code in preparation of a new feature. Prefactoring is perfectly normal on any XP project and in-fact indicates a healthy ongoing design process.

The distinction grew in my mind when we were facing a lot of exiting code debt. I needed a way to distinguish between the 'repair work' I was doing and the 'perfectly acceptable design work'. This was in response to questions like "How much more refactoring is left?" which really meant "How much repair work is left?".

A quick word on Prefactoring and Iterative Design.

Ideally your design applies the OpenClosedPrinciple, which would imply that adding new features would simply require you to add new code. That is great as long as the feature fits one of the axis you have opened your design to change.

However YAGNI indicates you should keep your code as simple as possible. Attempting to open your design to changes in more ways than you currently need can be over-design.

The solution is that you keep your code simple but Prefactor when you need your design to be open in a new dimension. You can then simply add the new feature by adding code. Utopia!

Splitting the work into these two steps makes implementing new features a much simpler process. The new tests are always easy to write. The design always nicely accommodates the the new feature.

As ever, I appreciate Rob for shaming me into finally blogging about this and helping me separate the dumb ideas from the gems.

Dynamic .Net

Thanks to LinFu C# has DuckTyping, MixIns, MultiDispatch and much more...

I'm already used this library for a new open source project, I'll blog on that next.

NCoverCop trunk... for coverage

If you grab NCoverCop from svn you can check out a couple of improvements.

• Refactoring Allowed.. If you delete tested code that is no longer needed, then this will unfortunately have the side effect of dropping your coverage percentage. NCoverCop allows for this by checking the number of untested lines. If it has not increased then the build is passes as you didn't make things worse.


• Coverage Differences are displayed when a build fails to give you an idea of the lines in the file that have become uncovered, or been added without test.


• sectionOfFilePathToCompareRegex allows you to specify a section of the document paths in the NCoverResults.xml files to ignore when comparing the files. This allows you to compare the build's file with your local one even if your trunk paths differ.

          coverageFile="${ncover.output.filename}"
          minCoveragePercentage="59"
          previousCoverageFile="${ncover.backup.filename}"
          autoUpdate="${environment::get-machine-name() == debug.buildbox.name}"
          sectionOfFilePathToCompareRegex="trunk.*"
     />

E.g. "trunk.*" (as above) will truncate "C:/something/trunk/somedir/file.cs" to "trunk/somedir/file.cs" when comparing with another results file.


Let me know if you find NCoverCop useful.


Note: Big big thanks to VarianInc for allowing me to do some work on NCoverCop on their dime. They have introduced a policy of using opensource code wherever they can, and contributing back to the community.

Varian (Melbourne) are by far the most agile company I have worked for to date. I highly recommend anyone that is keen to be part of a well functioning agile .Net team to get in contact with them. Email me and I'll forward your details if you like.

Unveiling NCoverCop

Duncan Bayne (who I have the pleasure of working with at the moment) had the idea of writing a small exe to parse an NCoverResults file and fail a build if the coverage drops below a set threshold. I loved it... and decided to up the ante.


From that seed I have built NCoverCop.

NCoverCop is a custom NAnt task that not only fails your build if your coverage drops, but lifts the threshold each time a new build passes with a higher threshold.

It works by keeping a copy of the best coverage file.

Here's how I use it..

  
              coverageFile="${ncover.output.filename}"
          previousCoverageFile="${ncover.backup.filename}"
          minCoveragePercentage="65"
          autoUpdate="${environment::get-machine-name() == debug.buildbox.name}"
     />
  

• coverageFile is the location of the NCoverResults.xml file you want to compare.


• previousCoverageFile is the file that will be overwitten if a successful build beats the current threshold.


• minCoveragePercentage is used when you don't have a previousCoverageFile yet or the specified percentage is higher than that of the previousCoverageFile.


• autoUpdate can be turned off so the previousCoverageFile doesn't get updated in a passing build.[defaults to on]

Here are a few tips...

We have the previousCoverageFile in a location that is visible on the network and referenced in the build file through it's network address. Coupled with being able to turn autoUpdate off for everyone except the build machine means that you can run ncoverCop locally and see if you are going to break the build before you check in.