I use dependency injection pattern on all projects where it makes any sense, especially spring is following me all my life. Once I’ve discovered domain driven design, I’ve realized that model should be rich, clear, reusable, no meaningless dependencies.
Combining of clear model along with spring annotation can bring few issues except model dependency on spring jar files.
See following example what’s going on:
And relevant unit tests.
Once you decided to write reboust component, you can’t be absolutely sure that someone will use spring (or other DI framework) to push all dependencies.
Well, you need them check. Those are the reasons why I decided to use dependency injection via constructor. The componets just use fully supplied constructor requiring all mandatory dependencies.
See the code:
Such code brings couple of other advantages which you must not see at a glance:
- Obviously clearer code as there is just only one place where all dependencies are injected and they are final.
- Simple tests
- No more @components with tons of dependencies. This is key point. Do you remember classes which grew and grew and when you opened them last time in your favorite IDE, they had more than 15 dependecies? Well, this is not possible any more. Who would maintain constructor using 15 parameters?
- No circular dependencies. Spring allows to define bean references which leads into closed circuit. I’m surely not alone who do not like it because it’s antipattern which hide some wrong design. Once you use dependency using constructor, you will not be able to write such relation anymore.
You can browse the code in GitHub.
Attaching presentation I made for my colleagues regarding unit testing. Google docs version.
I finished the reading of The Art of Unit Testing: With Examples in .Net book before a week. The book was categorized as an agile book so you can forget as the book is something like the bible of unit testing. It just summarizes the agile and pragmatic point of view to unit testing more then programmer’s manual how to write correctly unit tests.
First chapters define unit testing basis, point to differences between unit and integration testing. The problem is that such text doesn’t highlight those differences enough and the reader couldn’t understand why the isolation is so much necessary. It’s followed by the expression of stubs and mocks and the list of mock frameworks.
The rest of the content is sort of novel about importance of unit testing, the purpose of testing in the company. The most valuable chapter is almost last one which describes how to implement unit testing as a new feature in your company. Such text is applicable for any new technology you want to use in your business.
As I’ve already said, this book is sort of novel about unit testing, one text which can help you to form your point of view why and how to unit testing, that’s all. There is lack of facts important to understand how and why to use isolation frameworks, what can happen when you would write w/o that – which happen in my company anyway 🙂 – how you would “unit test” any class etc.
Just read the book to complete your glance of unit testing but not suitable for unit testing novices.