• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is Guice/Dependency Injection really meant to be universal?

 
Ranch Hand
Posts: 53
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm new to dependency injection and started to study Google Guice. I get the IOC concepts and all that, and how to bind and inject dependencies. But what I'm trying to wrap my mind around is whether it is meant to be a universal design pattern for all applications (big and small), or only in testing-intensive environments.

I work on a small team of three people, and we build commercial Swing applications for about twelve internal users. We deal with a lot of complexity and rapid business changes, doing release cycles every two weeks. We have established our best practices for our needs with a huge emphasis on immutable class design.

I currently can only see about 10% of our classes being leveraged through dependency injection, mostly database-related classes and parameters. But the other 90% I don't really see the benefit of creating interfaces to things we really only need one implementation of. It's just more boilerplate. I can see that would be helpful with testing but there's just a lot of class dependencies that I don't really see the value in decoupling. Maybe I'm just not seeing the big picture. Is Dependency Injection really supposed to the drive the design of every single class that has a dependency on another class, even if it the dependency is trivial or seems inconceivable another implementation of that class would be used? Or is its usage meant to be used judiciously and primarily for testing-intensive designs? What am I missing that would make me drink the DI Kool-Aid?
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ofcourse dependency injection is not a silver bullet which will solve all possible problems. It's just another tool that can help to decouple classes, making it easier to for example replace dependencies by mocks in unit tests.

Like with all tools, you'll still have to think for yourself about when best to use them. It would go too far to try to replace every use of the 'new' operator with dependency injection, that would just make your code more complicated without any real benefit.

I'd start by using it in a more coarse grained way. Your application probably consists of a number of modules or layers, for example a database access layer, a model, maybe some services to access other external systems. Make interfaces for the modules, and use dependency injection to inject the appropriate implementations. Only if I see that there's a benefit to apply it in a more fine grained way, I'd also apply it there.
 
Tom Nielson
Ranch Hand
Posts: 53
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesper de Jong wrote:Ofcourse dependency injection is not a silver bullet which will solve all possible problems. It's just another tool that can help to decouple classes, making it easier to for example replace dependencies by mocks in unit tests.

Like with all tools, you'll still have to think for yourself about when best to use them. It would go too far to try to replace every use of the 'new' operator with dependency injection, that would just make your code more complicated without any real benefit.

I'd start by using it in a more coarse grained way. Your application probably consists of a number of modules or layers, for example a database access layer, a model, maybe some services to access other external systems. Make interfaces for the modules, and use dependency injection to inject the appropriate implementations. Only if I see that there's a benefit to apply it in a more fine grained way, I'd also apply it there.



Okay that makes perfect sense. Thanks!
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic