Ok, Now for the good stuff…

Well, we’ve been waiting for long enough!

Yeah, I know, but I’ve been busy, give me some slack! So, all the stuff I did back in Jan looks great. Sometimes you come back to stuff that looked great at the time and it just looks like a steaming pile of turd, but this, mostly seems good. The move towards interfaces over classes, starting to use IoC containers, moving to composite aggregation rather than inheritance just leads to a nicer developing experience.

IoC what now? Isn’t that something to do with the Olympics?

Haha. IoC containers are just a way of physically constructing objects. So normally, you do something that looks a little like this:

var mynewobject = new SomeObjectType(dependency1, dependency2, dependency3);

This is “dependency injection” the mynewobject now has references to the instances dependency1, 2 and 3. Nothing ground breaking here. But, the thing is, we’ve just created a dependency in the method that calls that line to not only SomeObjectType, but also dependency1, dependency2 and dependency3. The method needs some reference, or way of constructing these instances. This is where the Inversion of Control steps in. In your constructor, you simply list parameters that the class will be dependent on. Except, rather than listing these as classes (which you can if you want) you list them as interfaces. So now, you’re not actually dependent on anything other than an abstraction of what it is you require. This makes the purpose of a class much much clearer, you only list the things that this class is actually interested in. As a bonus, you don’t have to go around passing references of things that you don’t actually want, just so that one of your members members member can access it. To top it off, it means the class is very easily testable using a testing framework like Moq

Moq? What the hell is that? Some kind of sports jacket?

No, that’s Coq Sportif. Moq is a testing framework. Basically, you start with an interface, point moq at it and through a little black magic and voodoo, you get a class that implements said interface. You then get to specify delegates and data values for each of the members (if you want to). Then, you pass it into the thing you’re testing, and when the test is finished, you can interrogate the moq object to see what methods were actually run. Neat huh?

But isn’t unit testing for losers?

That’s a commonly held belief by a lot of people, but make unit testing as painless as it is when you use dependency injection and Moq, and couple that with a test run framework like NCrunch and unit testing really comes into its own. Whether or not you do fully fledged TDD, or just want to test fiddly things to make sure they work right, it’s up to you. NCrunch is probably my most favourite thing at the moment. It doesn’t actually do anything that new, in the same way that ITunes main feature wasn’t that it could play music. ITunes power was in the way it let you work, it’s catelogue of your music content that let you search it in real time.¬†NCrunch continuously runs all your unit tests (and supports pretty much every framework out there) without recompiling, or even saving.¬†So, you write a test for some bug, and because NCrunch is integrated with visual studios editor, you get immediate feedback to whether or not you’ve satisfied your test, or broken something. You get a little green circle on a line of code whose tests all pass, or a little red circle if not. It also gives you full exception information as to why your test failed!

Sounds awesome, if you like testing!

Well I do. Testing has saved my ass many times. You’ve got a bit of functionality that you can’t quite pin down? Write some tests around it so that a) you’ve fully defined how the code should function and b) then when you do the work you can be confident that it actually works. The when c) you inevitably break it by attempting to tack on functionality/ edit a depenency, you know straight away and you don’t have to start at square 1! You can even use it to enforce business rules in your code. Want a message interface that must be inherited from once and only once? do some reflection and stick a unit test around it.

Anyway, it’s getting late and I’ve got a lot to do tomorrow. More posts coming with changes made recently!

This entry was posted in Project Icarus. Bookmark the permalink.

Leave a Reply