1. Hum, perhaps I'm doing more work than I need to...perhaps just out of habit of previously using manual factories...but I think I got this from the Guice online docs. Here is what I do:
Class A takes 4 parameters where all are interfaces of course. I add @Inject annotation to the constructor and optionally scope annotation to the class. I then create a module for this class that extends from AbstractModule that implements configure. In this method I create and maintain 4 bind() method calls that map the interface to the actual class. I assume the order of these bind statements much match the order in the constructor. Repeat for every IoC class in the application. I guess I just don't get your comment 'bind()ings are about *what* to inject, not *where* to inject them.' It seems you need some way to specify the *where* too. -Dave On Tue, May 10, 2011 at 11:17 AM, Thomas Broyer <[email protected]> wrote: > > > On Tuesday, May 10, 2011 9:25:08 AM UTC+2, dhoffer wrote: >> >> Thanks for the reply... >> >> Regarding 1 at a minimum I need the code/refactoring support one would >> get if using manual factories. E.g. If I add a constructor parameter >> or change parameter order I need it to keep the module/factory in >> sync. In IDEA reordering would change it everywhere, adding something >> new would have a default value. So it should at least add another >> bind() to the module where I have to fill out the types (and fail to >> compile until I do). As it is now I have to manually keep both in >> sync. My IDE has become Notepad. > > bind()ings are about *what* to inject, not *where* to inject them. Adding a > parameter to an @Inject-ed constructor doesn't mean you need a bind()ing, > unless your new parameter's *type* needs a bind()ing; but that's when you > create the *type* that you need to add the bind()ing, not when you use it. > Guice is all about not having to maintain "factories": if you need a new > dependency in a class, just add an argument to your @Inject-ed constructor, > or an @Inject-ed field or method; you don't have to go through hoops of > maintaining some factory. > Maybe you'd like your IDE to warn you if your app is missing a dependency > binding, but that's hard to do because Guice is about modularity: you > wouldn't want your IDE to warn you of a missing dependency if you're > developping a library where the dependency is meant to be provided by the > "context/environment" the library is used in (e.g. some library depends on a > JMS queue or JDBC connection, and the app that uses the library has to > provide the binding) > >> >> As a bonus the IDE should create the module as else the module really >> doesn't save any coding. But I understand this is not a Guice problem >> it's a desired IDE feature. >> >> 1b. Another example, with Guice I can't even ask the IDE to find uses >> of a constructor so I can find where it's used/created because that >> usage is hidden behind the magic of annotations. Again my IDE has >> become Notepad. > > Because the class should only be instantiated by Guice, and you should let > Guice inject it (i.e. not pass it around yourself), you can simply search > for uses of the class itself. >> >> 2. In the module for a class (which is its factory) > > No, the module only provides "configuration", the "factory" is the Injector > you build with it (and other modules). > >> >> I can have >> completely wrong bind statements and the compiler doesn't care. > > How's it different from having "completely wrong" code in a factory method? > >> >> It's >> not until runtime that errors are seen. Unit tests generally use >> mocks (that's why its IoC) so that won't catch the error either. I >> can add another test...really an integration test that causes Guice to >> create a live instance...that should catch any problems...but I'm >> concerned about that working in the general case because sometimes >> that will require lots of application code to fire up...not what is >> desired in a unit test. >> >> I guess my point here is that with manual factories those didn't need >> to be unit tested because with the compiler's help those are >> binary...you either have one or you don't...nothing really to test. >> With Guice lots can go wrong in the factory (Module). And because I >> have no IDE help to maintain the module...lots does go wrong. > > Can you give a concrete example? (code!) > >> >> 3. I'll review and see if I can make improvements in how I manage >> modules. To start I just had one package for these for the app...that >> was no good so now I name the module the same as the class with Module >> suffix and put in the same package as the class, that way I know where >> it is. I have one master class where I new up all the modules and add >> to Guice.createInjector(). Not sure yet how this will work. >> >> Thanks again for you help... > > -- > 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.
