On Tuesday, June 26, 2012 2:08:43 PM UTC+1, Christian Gruber wrote: > > > On Jun 26, 2012, at 7:49 AM, Paulo Pires wrote: > > > Hi all, > > > > This is a guidance request from someone who's interested in learning > Guice. > > > > I'm developing a Java SE application with some windows (SWT) that > interacts with the network (Netty.IO) and when some conditions are true > writes to a database by means of DAOs. Right now, my code is somewhat > tightly-coupled, so trying to put Guice to work is proving to be a true > PITA. > > > > My main issue is how to get instances from the injector in classes that > are 3 or 4 layers deep (not injected). > > > > I'd really appreciate if you could provide your approach on how you'd do > this. > > Can you give a simplified source code example? I'm not sure what you > mean. If a class isn't injected by the Injector, then you can't get it, > unless the injected classes expose getters that let you obtain it through > these means.
Imagine the following application workflow (I explain below): AppMain -> MainWindow -> NetworkTestWindow -> NetworkClient -> NetworkClientHandler -> ResultDAO AppMain - Where I instantiate my Injector and modules MainWindow - main SWT window for user input NetworkTestWindow - another window created from user input on MainWindow NetworkClient - class responsible for creating a network connection (instantiated from user input in NetworkTestWindow) NetworkClientHandler - class responsible for dealing with network events (onMessageReceived, etc.) ResultDAO - A DAO class that *should* have EntityManager injected (already initiated in AppMain) in order to interact with the database This was all tightly-coupled until some hours ago. Even though I can inject ResultDAO now, having to manipulate the SWT and network code to create windows with injection doesn't seem natural to me. Is it a bad-practice to have a class like AppMain as a singleton, get the injector from there and use it to get ResultDAO instances? > > > Often, it's very hard to move tightly coupled code into a > dependency-injection pattern, because it's really a substantial design > change. often, I find it easiest to start in one of two ways- at the top… > take the big object and put it in the injector (the one that creates all > its dependencies), and start pulling out those dependencies and injecting > them in turn. The other approach is to start with singletons, and re-tool > them so that their getInstance() methods have access to a global singleton > injector, and start migrating code that way. There are lots of migration > patterns, and which one is optimal is really quite dependent on your > situation. Could you developer further this "access global singleton injector" solution? Or even better, could you please give your insight on how you'd structure the workflow I described earlier? > > > But unless the Injector knows about the class (it's bound), then you can't > get it from the injector, you can only get it from a class that the > Injector knows about, which exposes it through accessors. > Yeah, I learned this the hard-way. Nonetheless, it makes perfect sense! > > Christian. > > > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-guice/-/0wr56UQHvgcJ. To post to this group, send email to google-guice@googlegroups.com. To unsubscribe from this group, send email to google-guice+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.