On point 1, I also struggled to grasp how Guice works, in part because I found the "dependency injection" terminology unilluminating. As far as I can tell, "dependency injection" just refers to the good (in my opinion) programming guideline that you should structure your class to receive all its dependencies as constructor arguments, rather than build them itself, and those dependencies should usually be interfaces or abstract classes, except when it's a simple value class or something. Guice goes beyond that. I eventually stumbled across two ways to conceptualize Guice that were quite helpful; maybe one of them will resonate with you.
1: Guice is just a Java way to initialize your app's baseline object graph at startup time. In that sense, a Guice Module it's a bit like a .nib/.xib file (if you've ever used Objective-C), except that a .nib file is based on serialization instead of runtime instantiation. Multiple module classes can be a way of breaking up an object graph that's naturally describable as separate subgraphs that share only a few connections between each other, but are more densely connected internally. 2: If you think of "object instantiation and dependency configuration" as a cross-cutting concern in the aspect-oriented programming sense, then Guice provides a framework for writing classes that handle that concern so that it's kept distinct from other business logic. In that sense, if you ever find yourself calling new() on an object that isn't expected to be released in the same scope, that's a "code smell" that suggests you should be putting something into a Guice Module. On points 2 and 3, I'll echo the points already made that you should be "injecting" dependencies through the constructor, not directly into your object's fields, even though the library supports it. (That's actually one of the reasons I found the "injection" terminology confusing at first: ideally, you're not so much injecting dependencies into an object (in the metaphorical sense of punching through the skin to set something internally), so much as you're feeding dependencies to the object through its constructor, where it can digest them however it sees fit). $.02, -Patrick On Mon, Nov 11, 2013 at 10:03 AM, Alan Darkworld <[email protected]>wrote: > Hello everyone, > > I've been working with Java for several years now and I'm always open for > new ideas to improve code quality. But I do have some serious doubts about > dependency injection (more on that later). However, as large frameworks > such as Eclipse 4 and Xtext employ it successfully, I'm trying to get used > to this new idiom. When walking through some tutorials, several questions > appeared: > > > *1)* The Injector becomes a sort of "main static factory" for the entire > application. However, Guice does not instance-control the injector - in > other words, Injector#getInstance is not static. How do you share your > injector across all classes in your application such that it's easy to > access? The easiest thing I can think of is to create it once at the start > of the program and then make it available through a static field, but that > just doesn't feel "right" to me. > > > *2)* I can see that DI is handy if all objects have no-argument default > constructors. But most of the time, this is not the case, especially with > immutable objects that need to check their invariants in their constructor. > Consider for example an immutable "DateRange" class with the invariant > "start date < end date". The only valid constructor for this class has two > parameters (the dates), yielding a client code like: > > long start = calculateStart(); // calculates the start time based on > user input (result is dynamic) > long end = calculateEnd(); // calculates end time based on user input > (result is dynamic) > DateRange period = new DateRange(start, end); // throws > IllegalArgumentException if start > end), need to replace this line by > Depencency Injection > > How would something like this translate into the Dependency Injection > idiom? I can clearly see DI working for the Java Beans pattern, but what > about the immutable case? I've had a look at the Guice Documentation, but I > couldn't spot an answer to this. > > > *3)* For many years, several books (including the excellent "*Effective > Java*") have gone to great lenghts explaining how to keep our class > invariants safe from both malicious access and careless programmers > (including client use and subclassing). By applying DI, we forfeit the > control over our fields, we give up on encapsulation. From my point of > view, with DI the focus has shifted from "*This class will work, no > matter how much you mistreat it*" to "*It works if you treat it right, > otherwise it's your own fault*". What implications does that have for > software quality? We sure gain a lot in terms of configurability (create a > new subclass, introduce it in the module and you're all set), but what do > we lose with respect to safety and contracts? This is actually my main > concern about DI and the very reason why I can't yet wrap my head around > it. Can somebody provide a reason why my concerns are without cause? Please > do! > > > I do have some more concerns about DI, but the three stated above are the > ones which really prevent me from getting into it. I'd be grateful if > someone could explain how to do it the right way (for 1 and 2), or why I'm > wrong (for 3). > > > Thanks, > > > Alan > > -- > 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. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
