Hi Scott, Thanks for the feedback. See my replies below...
-Dave On Wed, May 11, 2011 at 9:47 AM, scott <[email protected]> wrote: > 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. > [dh] I'm a IoC believer have been for a long time, so for me the move to Guice is not about adopting IoC, interfaces and mock testing, done that, the issue is using Guice or manually coding things. I still get the same decoupled tested design. What seems to get lost using Guice is how things are wired up. Doing things the old way I would have one really large method that boot-strapped the app, i.e. it simply created all the top level instances and injected where they needed to go. Factories were injected for objects created at runtime. One thing I read that Guice allows that I could not with the manual approach is circular dependencies...but I'm not sure I need that...I've only even wanted that once/twice. Also with the manual approach the issue of scope was explicit, it did what was coded. With Guice I understand I have a choice I can make things that would have naturally been single instances...either Singletons or new Instances...not yet clear what is best here. > > 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. > [dh] I'm going to try to write a unit test that causes Guice to create the object to see if this helps in this regard. I really don't want to wait until after deployment/runtime to find problems. > > 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. > > [dh] OK. I've only used Guice on one small app, I've got another that is much bigger and makes extensive use of generics...one of these days I aim to see how Guice works with heavily typed interfaces/classes. > 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. > > -- 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.
