I was recently made aware that being a java developer in this day and age that I should have working familiarity with the Spring Framework. Some of you already know that I have devoted November as Spring month and have been digging into it wholeheartedly.
What’s been great about the experience so far was having an “A-Ha” moment. As I’m reading about Spring, I learned its implementation of Dependency Injection solves a problem that had been bugging me in my personal project.
My project is a small, nothing-fancy RSS reader. Within the project is a FeedManager class. This class is dependent on two classes, an AtomParser and a RssParser. These two classes implement my Parser interface. When the FeedManager class is instantiated, its constructor creates the two classes and its kept as private variables within a Map. Doing this didn’t feel right in my mind, it was causing the FeedManager class to be tightly coupled with both the AtomParser and RssParser classes. Furthermore, if I need to add another feed format and continue following this design, the FeedManager class will become tightly coupled with yet another class. I knew this didn’t feel right, so I made a note in my code to find a way to have the parsers loaded via a configuration file some how.
And that some solution came. Spring’s use of Dependency Injection solves all that for me.
First of all, what is Dependency Injection?
DI is a way of associating application objects such that the object don’t need to know where their dependencies come from or how they’re implemented. Rather than acquiring dependencies on their own, dependent objects are given the objects that they depend on. Because dependent objects often only know about their injected objects through interfaces , coupling is kept very low.
Spring In Action, Walls, page 30
So how is this different? Well, instead of having FeedManager class creating its dependent classes, the Spring Container, through an XML configuration file, creates the dependent classes, places them into the Map, creates the FeedManager class, and the “injects” the Map into the FeedManager class. The FeedManager is only aware that it has a reference to a Map of Parsers, but doesn’t know much more than that. If I need to add another feed format, all I have to to is create a new Parser that implements the Parser interface and add it to the Spring configuration file.
The idea of Dependency Injection is that the dependent classes are “given” to the FeedManager, instead of the FeedManager creating them for itself. The concept of Dependency Injection is very simple stuff, but very powerful. You’re able to create cleaner extensible code.
What’s also great is that there is not much coding effort to utilize Spring. It took me about an hour to make the necessary changes in my project, and I think it actually shrunk in the number of lines of java code. And having a lot of that logic abstracted into separate configuration file is so much better.