Being provoked by your uncle
So there was a lot of commotion about two blog posts by Uncle Bob Martin; Dependency Injection Inversion and Mocking Mocking and Testing Outcomes. With replies from people like Jimmy Bogard “Poor use of DI versus need for DI” and Ayende “Rejecting Dependency Injection Inversion”. And also on Twitter there were many discussions going back and forth about it.
I would like to leave the discussion for what it is and focus on another aspect of the story. Apparently Uncle Bob was trying to provoke a reaction from his readers, but this was not very obvious in the blog posts themselves.
And that is something which I didn’t expect from my uncle. Usually my uncle is the one that provides very good insights and advice. Yes perhaps controversial and challenging but with a clear message. I mean normally it is the neighbor that is very provoking, I expect this from him so I read his posts in a completely different light.
I guess what I want to say is that if you have a certain established role within your community or team and then suddenly change the intent of your messages then you will mostly get confusion instead of anything else. In this case I believe my uncle would be able to send out the same message but in a way that is clearly provoking you to think. And thus achieving the wanted results I am sure.
Because there is absolutely nothing wrong about being provoked into thinking. On that note I am sure my uncle will continue doing so, in new ways perhaps.
You beat me to it! Oh well, I just posted on Uncle Bob’s blog post instead (the mocking post).
I’m not sure if Uncle Bob really has a valid point and is expressing it badly, or he is doing a Bellware on us — hoping that by pissing off the right people he will spark some more action.
@Chris Brandsma
I am sure it is ok to have multiple responses being posted on Elegant Code
Good point, it is strange when suddenly the role changes like that, but I think all of these “reactions” are highlighting a important point.
I said it before and I’ll keep saying it. The problem as far as I can see it is that the concept of DI is so critical is needs to be part of the language. I wrote about it here: http://simpleprogrammer.com/2010/01/22/call-for-a-programming-language/
Although I am a supporter of DI, (I had been doing it many years back before there were containers, as a way to support TDD), it is getting too complicated and convoluted now with so many frameworks popping up and so many rules which are not enforced, but are trade knowledge. I have always been of the opinion that a good framework feels like it isn’t even there.
There is a real gap between the concept of DI and the implementation of DI. Because of the tools we have, we are solving DI by using of a few patterns restricted by the language.
My 2 cents.
In order to change behavior, I think one of the keys of DI frameworks is that the construction of the object graph/instantiation instructions are not in Java.
Should they be in XML? Meh, okay, if you have nothing else.
Should they be in annotations in the code? Oh god no. See: hardcoding.
JSON may be more compact than XML, but less readable.
a DSL might be nice…
Or a scripting language like Groovy or clojure. I (complain (about (LISP (a (lot )))) but this may be an ideal use case for clojure and its tight integration. Or Rhino. Or Javascript.
Point is, a non-pure-java object graph construction process helps indicate a separation between modular code and the gluing of them together.
Spring is pretty good.
By the way, who thought it was a good idea to put the injection instructions in the “decoupled” code? Tthat code isn’t decoupled anymore.
@cowardlydragon
There is no good reason that configuration should be in a different language than the code itself. It’s more understandable to have it all in one language, taking advantage of the language’s features for type safety, etc. There are other ways of separating configuration from application code. In Guice, all configuration is done in classes that implement Module. Configuration is all these should do, and it’s easy to understand. Modules are collected and used to configure the application in its entry point, be it the main method or something else.
Second, injection annotations in application code are not coupling because they do not force the class to be used with the DI container. It does nothing when testing or any time you don’t set up the container to do something with it. It improves readability by indicating that the class and its dependencies are intended to be provided by the DI container, so programmers know where to look for that. And it allows you to safely make just about any changes you want to the class without ever having to touch your configuration code. Adding a constructor, adding a new dependency to the injected constructor, renaming a method used for injection… none of that can break your configuration. It makes a lot more sense than you think.
I don’t think there is or can be an issue with supporting or not supporting the concept of DI. DI is just a concept, nothing more or less. At best it’s a pattern, not [intended to be a] a philosophy that can shape us, or a rock star that can inspire or compel us, or a long standing business partner that we abandon when they give us a small hiccup in our standing arrangement of time, cost, or quality for our respective efforts.
The whole crux of the origin of the discussion seems to about a general disregard for the consequence of applying the concept of DI. What it boils down to seems more of a request to promote restraint or measured reluctance to DI, instead of viewing it as standard operating procedure or paradigm.
Must a situation in question utilize DI, or are there reasonable alternatives? It seems akin to outsourcing. Should we forgo control to a remote or 3rd party provider to accomplish a task in order to allocate local resources elsewhere? Are we going to be marketing and financing organization that sells brands and provides funds, or a manufacturing organization that sells products we built? Are we composers, conductors, or musicians? Is delegated extensibility or portability at the strategy or composition level always a good thing?
Perhaps I am not tuned into the intent of the original post, but that’s how I view DI: a concept if I must, I can; not if I can, I must. I think that’s “Uncle” Bob’s concern, just because you can DI, doesn’t mean you should. Further, if you must, do so with cautioned awareness of consequences so that DI is adequately measured and controlled.