I often work with clients / legacy code where Spring or Guice, i.e. DI, is not used. I really like the DI principle because it enforces loosely coupled code and thus makes my code more readable and testable. What would be a good strategy / argument to introduce a DI framework in the legacy code case? Refactor bit by bit and attack it from the service & unittest layer? Big bang? Any experience with introducing DI in legacy code?
Johan Pelgrim, The Netherlands
SCJP 1.4, SCWCD 1.4, SCBCD 5.0
I would certainly go for the bit by bit refactoring. Big Bang, as you put it, is really risky, will take a lot work time with no real difference that appears to the client. The Big Bang option might be useful if you are in a stage where no new features are asked to be added to the legacy code, and you are in a stage where code cleaning and refactoring is the main target.
Yes I have introduced it in a couple of applications from the ground up. The key is to start with the parts of code that are changing the most, then work your way outward. That way your immediate pain is eased a bit, and everyone on the team is using DI regularly and gets comfortable with it.
There are lots of compelling reasons in the political fight, you essentially have the good ones though: modularity, testability, loose coupling and reduction of error-prone boilerplate code.