David, You make some valid points about some of the drawbacks of using Guice and probably IoC in general, I've struggled to get the concept of dependency injection to catch on in my office because of some of the reasons you mention.
Its really a trade-off, by using an IoC container to wire your classes together you might be losing some compile-time checking that you would have by calling constructors directly, or calling factory methods, but that route will lead you down a path to a very tightly coupled application, that is not able to adapt to changing requirements or the addition of new functionality. You could say similar things about using interfaces, using lots of interfaces in your code makes it somewhat harder to read and follow what's going on, but I think most agree that using interfaces in logical places is beneficial and helps to create a loosely coupled application. Another huge benefit of using IoC is the vast improvements you'll see in the testability of your code. With respect to your complaint about not finding out about missing bindings until runtime (2), this is definitely true, but I've found that you discover the missing bindings pretty quickly as soon as you try to start your application for the first time, and maybe run a happy path scenario test. Misko talks about this a little bit in his unit testing tech talk (http://www.youtube.com/watch?v=wEhu57pih5w). Guice also supports a "PRODUCTION" mode (or Stage: http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/Stage.html) which will create all singletons eagerly and help expose missing bindings at startup. I sympathize with your issues of keeping track of modules, working on a large project we struggled with module organization also as we started using Guice in more and more places. We started with a module per application approach, but this caused a lot of duplicate code in different modules and forced developers to have to understand the guts of other developer's code. We finally settled on a module per "service" strategy, service is a pretty vague term in this context but it's generally composed of a group of related classes. With this approach, if one developer decides to use a service written by another, they know they need to install the module associated with that service. It seems to be working reasonably well so far, but you'll likely have to experiment with different approaches and determine the one that works well for your development environment. On May 9, 11:38 pm, dhoffer <[email protected]> wrote: > Okay I'm new to Guice so maybe I'm missing something but since I > converted one app to use Guice I've found some things that I just > don't like, I'm wondering if folks have found solutions or have > suggestions. > > 1. No IDE help. I use IDEA and as of yet it is not Guice aware so all > my refactoring/code support is broke. And I have to build the modules > by hand which is just as hard as making the factory manually before I > used Guice. So to me Guice just moves the problem around. At least > when I made manual factories the IDE could keep changes in sync. > > 2. Loss of compile time checking. Just by running the compiler I > can't tell if my code is complete, by that I mean have all the right > modules/parameters, I don't find out something is wrong until > runtime. Prior to this, using manual factories, this was a given. > Perhaps I need to add a unit test that forces Guice to create an > instance of the class so it least I could know during the test phase > that the module/factory is correct? > > 3. Can't keep track of all the modules. As best I can tell nothing in > the module code even says what class it's a factory for. There is too > much annotation magic going on, apparently @Inject is enough for Guice > to 'know' that someplace in vast numbers of Guice modules there should > be one that has the right mix of input parameters? > > What am I doing wrong? I feel like this is a couple steps in the > wrong direction. -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
