Wednesday, April 2

Dependency Injection

Non technical readers, avert thy eyes!

Really, don't keep reading, you'll glaze over any moment now...

Work is throwing up a couple of interesting aspects (for a change) with the possible use by the SI of the Spring framework to enable our product to support 'hot swappable' Process objects and make testing (apparently) easier.
Having not really looked at Spring before, I did some digging, a bit of playing on a local environment and found that I too could get it to flip the usual implementation class for a different one at Factory request time.

Setting aside the whole discussion of where I stand on firstly Spring, and secondly Spring and the employer's product, I think its generally a 'good thing' - developers have been moaning about EJB and JDBC and JNDI configuration for years, and the leveraging of the whole DI (dependency injection) paradigm makes clear sense too.

Anyway, trawling the interweb I spotted the story of a guy who basically knocked up his own simple version of a kind of Spring DI framework: interesting I thought, not just cos if how relatively easy it is, but also cos he relied on java to define the configuration, rather than XML, thus gaining the full benefit of type-checking and avoiding human spelling errors that inevitably come from the standard XML-based config that Spring uses.

The guy's article is here

No comments: