I have just joined a company where the major projects, including the one i have landed on, use Guice. I have never used Guice. I am familiar with dependency injection, in the shape of CDI (a bit) and the obscure but decent Nucleus (part of ATG).

We just completed a successful iteration, so tomorrow (friday the 13th!) is a day that developers have to spend on things they think are valuable. I have some meetings during the day, but i will have about four or five hours to do this. I have a machine to myself, with Eclipse installed and configured to my liking.

I would like to spend my day learning about Guice.

How should i spend my time?

(I'm not entirely sure this is an appropriate question for Programmers, but there's only one way to find out)

  • Do you understand DI and its pros/cons? That would be the first area to understand before concerning yourself with a framework. – Aaron McIver Jan 12 '12 at 16:21
  • @AaronMcIver: Good question, sorry for not mentioning that. Yes, i do; question edited accordingly. – Tom Anderson Jan 12 '12 at 17:25

Find a small program which has a Factory and rewrite the program so Guice can inject a provider you can use instead of the factory.

Note that the object in which the provider or instance is to be injected may not be created with a new but must be retrieved from Guice. This may require you to rework the inner logic a bit.

  • This is what i did, so accepted. Spent half an hour writing an integration test, then writing a program without any unit tests, filling it with as many news as possible. Spent a couple of hours writing unit tests and refactoring everything to be manually dependency-injected. Spent about five minutes porting the injection to Guice! – Tom Anderson Jan 14 '12 at 0:31
  • Also wasted some time watching some videos of Bob Lee and friends yammering about it all. It took them an hour to say what i could have read in five minutes. Thanks guys! – Tom Anderson Jan 14 '12 at 0:34
  • ...refactoring everything...: be careful later, you generally do not want each and every object to be injected. Only do it for those where you truly, really cannot decide until runtime which one you'll need. – user1249 Jan 14 '12 at 4:27
  • Fair point. I still say 'new ArrayList` and so on. But the refaction for injectability was driven by the desire to write mockist unit tests. I routinely do that even where there is only one choice at runtime. The ability to then Guicify the objects came as a free bonus. – Tom Anderson Jan 14 '12 at 10:43

My experience with guice is that a great way to learn it is just to pick a few different scenarios for something your company already has, think of a use-case for each one, and work on implementing them using guice principles.

So when I went to learn it I took an already existing REST server that I had been working on for my company. I decided not to greenfield it, since I find the only real way to learn a new toolkit is to use it on a real-worldish project, and we already had a unit test suite set up for that service, so I would know if I caused a regression. I set a series of goals for where I wanted to take the project with guice, the first three were roughly:

  1. Use guice to replace all of the various singletons, DAOs, etc. Essentially objects that are poster-children for dependency injection and where DI makes them easier to test. This meant I had to figure out how to get guice integrated with junit very early, and also provided an opportunity to abstract out some modules I wanted injected during test and some other modules I wanted injected when in production.
  2. Get as much of the application to show up using the Grapher as possible. This also had the advantage of getting most of it integrated via providers, modules, etc.
  3. Abstract out the logging we were doing in the entry-and-exit methods using AOP.

So at the end of this I had a great graph of how our classes were interacting, all of the unit tests were passing, and I had simplified and improved our logging facilities for the REST interface.

I had substantially longer than a day (and I also had a longer list, including getting the JPA persistence piece integrated), but those seem like reasonable areas to start with if you have a suitable project lying around (or can make one quickly, e.g., by creating a quick REST service to do something that might be useful or fun).

I do highly recommend starting with something that either has tests or that you can write some basic tests for quickly, since that will let you tweak things or completely replace components and ensure that everything is still working.

Hope that helps.

  • As i said in the question, i just joined the company, so i don't know any system well enough to do this, and in any case, also as i said in the question, the code already makes extensive use of Guice. – Tom Anderson Jan 14 '12 at 0:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.