Archive for May 2006
In a recent blog post, Cory Foy discusses an experience of reaching an understanding by analysing the process of comprehension. He links to an interesting article by Dale H Emery. Reading these reminded me of this post about misunderstanding. It is easy to underestimate how easily misunderstanding can occur and what the impact can be. The advice in this post is worth heeding.
On a train the other day I saw a map on the platform. At first I found the map a little confusing – then I figured out why. Maps show the north at the top, which means left is west. On the train I was on the seats face the other side – so you move sideways. The train was moving eastwards – which was to my left. So the map was backwards compared to my experience. Made me think about the assumptions in the diagrams I draw and read.
I’ve been meaning to blog about the anatomy of nspectre for a while now. nspectre consists of 2 distinct parts: configuration and a runtime.
The configuration has at its root the Settings class in the NSpectre.Core.Configuration namespace. This namespace also contains a couple of implementations of IConfigurationReader that read XML into the configuration, which can be thought of as a (sort of) Domain Specific Language (DSL.) The DSL provides a means to model the conditions required for a type to be valid for a given action. The reason I say sort of DSL is that the templates are, essentially, C#. However, by leveraging CustomSpecifications, these templates can be abstracted.
The main class in the runtime is IValidator. To create an instance of IValidator, you use IValidatorFactory – and to get an instance of IValidatorFactory you create an instance of Initialiser. The implementation of IValidatorFactory compiles the Settings the first time an instance of IValidator is requested.
Time for a little meta-blogging. I read this post earlier this week with interest. There's a few blogs I read regularly. Of these, there's a couple I read purely for the content, but most are links along with commentary and context. The comments and links on posts are also valuable. Without this linking, the fabric of blogging is thin (the Emperor's New Web?)
In my post last week I discussed a solution for having control over the class being created by the class being tested. There is another way of doing this that is worth mentioning: creating a Factory class. Let's assume we created an interface (IBar) that our Bar class implements. Now we need to create a class (BarFactory) that contains methods for creating instances of Bar. I am inclined to take this one step further and create an interface for the factory class (IBarFactory which will create instances of IBar.) Now we can pass an instance of IBarFactory to Foo in the constructor. We can mock IBarFactory and ensure that we are only testing Foo.