File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Introducing DI in legacy code Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Introducing DI in legacy code" Watch "Introducing DI in legacy code" New topic
Author

Introducing DI in legacy code

Johan Pelgrim
Ranch Hand

Joined: Jul 07, 2003
Posts: 105

Hi there,

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 & unit test layer? Big bang? Any experience with introducing DI in legacy code?

Cheers,

Johan


Johan Pelgrim, The Netherlands
SCJP 1.4, SCWCD 1.4, SCBCD 5.0
Alaa Nassef
Ranch Hand

Joined: Jan 28, 2008
Posts: 467
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.


Visit my blog: http://jnassef.blogspot.com/
Dhanji Prasanna
author
Ranch Hand

Joined: Aug 30, 2009
Posts: 38
Certainly not big-bang.

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.


Software Engineer at Google

http://twitter.com/dhanji
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Introducing DI in legacy code