tag:blogger.com,1999:blog-5427069094580312550.post4955366638138678889..comments2023-12-23T21:48:09.231-08:00Comments on Code To Joy: Out of the Ether: Dependency InjectionMichael Easterhttp://www.blogger.com/profile/14799771593145201161noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-5427069094580312550.post-50235806366301718272007-06-08T05:18:00.000-07:002007-06-08T05:18:00.000-07:00Why not just mandate that it has a constructor (or...Why not just mandate that it has a constructor (or setter) that accepts the dependencies? Either they're implementation details and shouldn't be injected, or they're dependencies and should be available for any framework (including plain old code) to use.<BR/><BR/>If it doesn't satisfy these requirements, it's not loosely coupled. If it does, it is - why does Guice demand special treatment?<BR/><BR/>If you provide a special constructor for some privileged framework to use, you're pretty much guaranteeing that other frameworks have less privileged access - why write your code to the one framework instead of following the loose coupling principle more generally?<BR/><BR/>In short, why do you feel the need to draw a distinction between "clients" and DI tools? Why aren't DI tools just clients?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5427069094580312550.post-57270402652015455732007-06-07T19:27:00.000-07:002007-06-07T19:27:00.000-07:00Eric's site has a post that talks about Guice's u...<A HREF="http://stuffthathappens.com/blog/2007/06/06/constructors-areare-notareare-not-part-of-an-api/" REL="nofollow">Eric's<BR/> site</A> has a post that talks about Guice's use of constructors.<BR/><BR/>One way to think of it is this: as the class author, one gets to define the "gateway" (ctor) for clients and for DI tools. <BR/><BR/>If we don't define the initializer/ctor for the DI tools, then what choice do they have but to use bytecode manipulation, or to mandate that fields be protected/public, all of which would draw stronger criticism.<BR/><BR/>There's no free lunch! But the cost to "drink the Guice" :-} isn't very highMichael Easterhttps://www.blogger.com/profile/14799771593145201161noreply@blogger.comtag:blogger.com,1999:blog-5427069094580312550.post-13331717243501398742007-06-07T06:52:00.000-07:002007-06-07T06:52:00.000-07:00"with Guice, his constructor would not be part of ..."with Guice, his constructor would not be part of his public API"<BR/><BR/>I still don't buy it. Why write code to the Guice framework? Surely it's Guice's job to work with my classes, not the other way around? I thought that was kind of the point!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5427069094580312550.post-87015224468802371732007-06-06T09:53:00.000-07:002007-06-06T09:53:00.000-07:00There have been valid criticisms of this post. I'...There have been valid criticisms of this post. I'll put a comment in a "ps" section in the post itself.Michael Easterhttps://www.blogger.com/profile/14799771593145201161noreply@blogger.comtag:blogger.com,1999:blog-5427069094580312550.post-83587298507335118242007-06-06T09:46:00.000-07:002007-06-06T09:46:00.000-07:00Dave, I'm not sure I would go so far as to inject ...Dave, I'm not sure I would go so far as to inject Map implementations either (@Inject @Hashed Map?), but with Guice, his constructor would not be part of his public API. Guice calls your constructors. Other classes just depend on your interface. They don't worry about how you get created, remember? As a client of your class, I don't want to know you need a Map, but I also don't want to know about any of your other deps.Bobhttps://www.blogger.com/profile/17659001534221131143noreply@blogger.comtag:blogger.com,1999:blog-5427069094580312550.post-14004457742487059532007-06-06T06:49:00.000-07:002007-06-06T06:49:00.000-07:00Couldn't agree less. Map is an implementation deta...Couldn't agree less. Map is an implementation detail here. By making it part of the public interface, you've just created (not removed) a hard dependency. Now you can't change it to a List or a Set based implementation without completely screwing over any client code that's been built around it. Nice.Anonymousnoreply@blogger.com