how to use guice properly.

[Maatary Okouya]

Hi, 

I have been using google-guice for few months now. I'm quite satisfied with it, but it seems that i'm using it wrong. I'm creating a lot of assisted-injection and sometimes two injectors.

Hence i would like to understand the general principle here. 

Does one should have one injector for the all application that wires everything from the main class ?

Would the best practice be about, trying to inject has much in the constructor from the start of the application ?

My main problem with this is that sometimes i feel like the creation of some groups of objects belong to certain component. That there is a need to encapsulate that? How would you deal with that?

When you have an important deep structure of interconnected lservices, how do you do to pass the injector or the object required. You must find a way ? I have resorted a lot in assisted injection.

Even when the parameter could have been created outside of the object, i still prefer to let the service create the parameter and pass it to the assisted factory. Because the creation of the parameter sometimes involve some logic that belongs to the service (sometimes)

Any suggestion would help

Many thanks

[Jochen Wiedmann]

I'm not sure, whether I get you right. But to me this sounds like a situation where I would create child injectors and somehow make sure that they are accessible. For example, in a web application, I might create a parent injector for the whole web application. And, for any HTTP Request, I might create a child injector with request specific data (a database transaction comes to mind) and store that in a ThreadLocal.

OTOH, my example might interfere a lot with scopes. But, to be honest: I never really understood what scopes are good for.

Jochen

[Thomas Broyer]

On Thursday, August 21, 2014 8:43:18 AM UTC+2, Jochen Wiedmann wrote:

I'm not sure, whether I get you right. But to me this sounds like a situation where I would create child injectors and somehow make sure that they are accessible. For example, in a web application, I might create a parent injector for the whole web application. And, for any HTTP Request, I might create a child injector with request specific data (a database transaction comes to mind) and store that in a ThreadLocal.

OTOH, my example might interfere a lot with scopes. But, to be honest: I never really understood what scopes are good for.

Scopes would be a good fit when child injectors don't work. E.g. you have some object that's a singleton or quasi-singleton (because reasons; part of a framework for instance) but needs access to objects with a shorter lifetime (things that would otherwise belong to a child injector in your book, but that would be impossible here); in that case, the singleton object can be injected a Provider<OtherObject>. When it knows it needs to reuse the same OtherObject instance, it makes it so that it calls Provider#get once only; when it doesn't care whether it's the same instance as before, it calls Provider#get; and whether it gets the same instance or another one is not its responsibility.

Also, "child injectors" are not part of JSR330 whereas scopes are, so scopes are more "portable" than child injectors, and classes can elect to be used in some scopes by being annotated themselves whereas with child injectors you'd rely on the wiring of the injectors and not messing things up.

(note: Dagger uses child injectors to implement scopes; AFAICT it forbids mixing scopes with a Provider<> but that's generally thought of as a bad practice anyway, AFAIK)

[Maatary Okouya]

Thanks for your inputs. Basically, One injector for the all application is not always possible.

On Thursday, August 21, 2014 8:43:18 AM UTC+2, Jochen Wiedmann wrote:

[Thomas Broyer]

On Thursday, August 21, 2014 11:22:58 AM UTC+2, Maatary Okouya wrote:

Thanks for your inputs. Basically, One injector for the all application is not always possible.

I believe it generally is; you'd then use scopes to group things together.

[Maatary Okouya]

Your recommendation however, is to try as much as possible to rely on only one injector, that instantiate the different modules as required. 

To make my question simple, do you carry around your injector within the code, or you keep the injection in one place ?

I find myself in many situation where i feel like i need to let the creation happens at different position in my code. I don't know if it is normal to have assisted injection everywhere. 

I never used providers. But i think we are in the same situation. 

Let me take one example. 

I have a Service A that needs a Service B. However, B needs a parameter, that requires some computation in A first to happens. I always end up creating an assisted factory with one parameter only? Is that the right thing to do here ?

This leads to another question that i have in mind: Is it ok to have a parameterized module? In the sense that, you have a constructor of your module that takes parameters. Why i'm asking this, well i have the following situation. 

I'm using JavaFX2. I want to encapsulate/modularized the creation of my interface. In javaFx2 everything happens in the Application.start method which provide you with the primaryStage. 

override def start(primaryStage: Stage): Unit = {

//Create your interface here

//initialized whatever else you may think of here (could launch a thread as well)

primaryStage.show()

}

I have an interfaceBuilder class that takes the primary stage as parameter. At least for now. I see two solution here when using guice. Either an assisted inject, or a module that is parameterized. 

Also, when my interfaceBuilder has build the interface, i can get from it the different Component that it has created. For example, BuildInterface(): AppInterface. where AppInterface, contain the relevant component that i need: TreeView, StartButton, TextArea, etc.. AppInterface is in a sense a data Structure. 

Now the interesting part here is that, out of those component i need to create, Services that handle them. TreeViewService ( which in my application, participantViewService) They independently encapsulate the logic to manage the logic related their component. TreeViewService takes the TreeViewComponent has parameter in its constructor. In the more complex version especially for the StartService and the shutDown Service they take a controler or whatever class that encapsulate the management of the application as parameter. 

This is the simplified version. but as you can see. At every step of the way, i need some parameter to be provided  for the creation of my service. InterFacebuilder Service needs the primary stage,  The other view Service needs the the view component created by the InterfaceBuilder and another component (e.g. Controler) provided by the Application creation Logic. 

How would you deal with that in this case? Assisted Injection, Parameterized Modules ? 

PS: I'm not using the SceneBuilder of JavaFX2