If i follow you well:
- If B needs something that A inject in it, You would rather to the injection yourself, before injecting B into A. What about the case where, A is really doing some specific computation that is necessary to get the parameter that B need. I think sometime a partial injection is not a bad thing, don't you think so ? - *If B only needs 'assisted' parameters, then I simply avoid creating the factory and binding it -- since it all becomes overhead. You've got to draw the line with some "primitives" and I've found this to work well. If you ever need it injected in the future, it's a simple change to introduce a factory (perhaps tedious, but definitely simple). This is not clear to me !! Could you clarify that. Especially i don't understand what you mean by primitive. * On Thursday, August 21, 2014 11:31:34 PM UTC+2, Nate Bauernfeind wrote: > > I think this is a really good question and I think that your concern > centers around the difference between injection and initialization. > > In the case of B depending on A initializing something this is my opinion: > > Clearly, you have some dependency in the order in which things are > initialized. When I find myself in this situation I tend to implement a > Managed interface (with a start and stop), and then explicitly start all > instances of type A before all instances of type B when that dependency > exists. > > When you have many instances of A's then this becomes cumbersome and I > usually use some other class that manages creation and deletion of these > since they've been more organic in my applications. If you can get away > with multi-binding, that's probably reasonable (with a static known number > instances of A). But if there's just one A I tend to actually start it > immediately after creating the injector. > > If B ever needs something that A injects, I prefer to inject it into B > (since A changes over time and it's easy to miss the fact that the only > reason a dependency lingers was because it was being passed on down into > B). Even if you need to initialize it in some fashion in A. > > If B only needs 'assisted' parameters, then I simply avoid creating the > factory and binding it -- since it all becomes overhead. You've got to draw > the line with some "primitives" and I've found this to work well. If you > ever need it injected in the future, it's a simple change to introduce a > factory (perhaps tedious, but definitely simple). > > Others may have other opinions and preferences though, of course! But this > has treated me well in projects large and small. > > Nate > > > On Thu, Aug 21, 2014 at 10:08 AM, Maatary Okouya <[email protected] > <javascript:>> wrote: > >> Clarification: >> >> When i say: * I'm saying this because I always thought that, creating >> things somewhere that is unrelated to the class/service that is going to >> use it sounds odd to me.* >> >> *I do not mean that i do not adhere to separating usage from >> construction, but i would rather do it in an enclosing class something like >> that. Not in a place far away completely unrelated.* >> >> >> On Thursday, August 21, 2014 4:48:26 PM UTC+2, Maatary Okouya wrote: >>> >>> Hi, >>> >>> I'd like some advise on the use of assisted injection. >>> >>> Most of the example that i saw about assisted injection, have the >>> following characteristic: >>> >>> >>> - The class being constructor has a parameter, that comes one or >>> more parameter that only comes at runtime, that is, that can't be >>> determined at construction time, and one or many parameters that are >>> known >>> at construction time. Hence, the create method of the factory only >>> takes, >>> the parameter provided at runtime. >>> >>> >>> In my case 90% of the time, i just have the runtime parameter. Meaning, >>> I have a class A that needs a class B, but B takes parameters that only A >>> can provide. So there is only @assister Parameter in the constructor of B. >>> >>> I'm wondering if that is the proper usage of assisted injection. >>> >>> One of my last example is the following. A needs to return a class B >>> that is a "dataStructure" (sometimes called DTO, or value object), hence i >>> pass to A the necessary factory, so that after its computation he can >>> return B.Here B, is like a container class. I have few case like that. >>> >>> The other situation is when service A needs the B Service, but B service >>> depends of a Parameter from A upon creation. Where the parameter from A his >>> himself injected to A, however, A does some initialization on it, before >>> creating B with it. >>> >>> Especially in the last case shall i aim to do the *"internal >>> initialization of A"* outside of A. *The idea is to have specific >>> creation modules in each package, that externalizes the "internal creation >>> of the services" of that package? I'm saying this because I always thought >>> that, creating things somewhere that is unrelated to the class/service that >>> is going to use it sounds odd to me. With my current understanding, each >>> package should provide its creation module, that centralizes the creation >>> of the object that it contains, especially if one use private constructors.* >>> >>> I have used Guice so far for a while, but it is just recently that i red >>> something about separating module, and keeping module with their package. I >>> use to do inheritance between module to chain the creation of object, and >>> ended up having one module that creates everything from start. That is >>> wrong right ? >>> >>> So that is it. I would appreciate some general advice on the right >>> approach in using Guice. I'm not sure that i'm using assisted injection the >>> right way. >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "google-guice" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/google-guice. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-guice/ecb0b6e6-0475-42eb-8ef8-8b53df62f109%40googlegroups.com >> >> <https://groups.google.com/d/msgid/google-guice/ecb0b6e6-0475-42eb-8ef8-8b53df62f109%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/547942dc-f972-48e5-8d46-2f6766b86a8f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
