Hum what do I need then? When do I need an AbstractModule? This link is one of many that show doing it the way I described... http://code.google.com/p/google-guice/wiki/GettingStarted
-Dave On Tue, May 10, 2011 at 12:15 PM, Peter Reilly <[email protected]> wrote: > On Tue, May 10, 2011 at 9:47 AM, David Hoffer <[email protected]> wrote: >> 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. > ekk, > you certainly do not need to do that. > For most classes you do not need to have anything in an AbstractModule. > I use it mostly to add in old non-guiced classes and for these I normally > use a @Provides annotation on a method in the module. > > Peter > >> >> 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. >> >> > > -- > 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.
