Rusty Elliote Harold has an amusing comment on Guice and how dependency injection contributes to code obfuscation. I agree with him, though the IDE can make the navigation of the where beans are coming in easier, for instance IntelliJ has it all over eclipse in this area, but, for spring anyway, it usually means going back and forth between xml and java code and then finding that it craps out at runtime rather than compile time which removes one of the benefits of a strongly typed compiled language. Harold writes:

I've been using Guice at my day job for the last year, and not by choice. I find it makes our code base far harder to comprehend and work with. ... As far as I've been able to see, all dependency injection does for us is make unit testing edge cases a little easier ...

We haven't been using dependency injection for unit testing, so I don't have any experience there. One of the pains of complex software systems is configuration. It is a stumbly mess where you to get things running perfectly you have to modify this, test, modify that, test, etc etc. We mainly use dependency injection in a configuration sense. Our software engineers are more comfortable working in code itself, so it is often easier just to explicitly put a reference in a class anyway as it is directly in their competency domain.

A good example of that is how developers when doing dhtml often stack their javascript with all sorts of CSS information. I have seen that in the past, and it is simply because they are more comfortable manipulating CSS from within the language of javascript than CSS itself. That is bad design, javascript shouldn't do anything more than display:none and display:"" along with changing the class attribute. However it is a good example of how software developers are more comfortable in the code itself, than in configuration. Harold continues:

One should not complexify a class's API purely to make testing easier. Testing exists to serve the model code, not the other way around. To cite the classic dependency injection example, if the only reason you pass a Clock object to a constructor instead of creating one privately inside the class is to support unit testing, then don't do it. Unit testing is no excuse for heavily coupled classes exposing their private parts and violating encapsulation. When forced to choose between good object oriented design and testability, choose good object oriented design.

We are hitting similar issues in our project. We are having to make design compromises in encapsulation simply to expose variables to automated unit testing.

I often think that many of these conventions are applied too widely, software being software and largely a young person's game, it is hopelessly exposed to software hipsterish tech fashion. DI is cool, lets make everything DI! Patterns are cool, lets never speak in plain English again, and lets make all our objects and structures adhere to the patterns in the GoF book!

I hate it when you are talking about structures and the pattern language gets in the way. For instance I was talking with a co-worker about undo which is usually expressed in the Command Pattern (and which we implemented in another system that way). However in PureMVC the command patterns are used as Controllers. And because of that we had a disconnect about what were commands and what were controllers.

I also dislike when someone is talking about software and discusses a pattern they are intimately familiar with, and I am not (the GoF book has 22 patterns in it), and I think, "Oh man, don't make me go and look up a book to work out what we are talking about." I keep the GoF book on top of my powermac, I am the only one in the office that does that, and I use it as a reference when other people throw patterns at me that I am not familiar with.

I am sure that half of all pattern discussion is done from ignorance, or with the one talking about the pattern not being absolutely certain what it actually is; "We should put an Observer in here, or a Visitor, maybe a Cromulator and Confabulator would be better!"

There is a reason that every software interview asks about singletons. It is the only one simple enough to remember off the top of your head. Also, because of that, I think singleton is hopelessly over-used in software simply because it is the simplest pattern structure, just one object, that a developer can use. As a result good Object Oriented structures are often littered with getInstance() or even static create() methods.

I don't know. There is a time and place, and all those folkisms, is probably a good summary for what I have written above. Use in moderation and without an eye to fashion or doctrine. Disclaimer, disclaimer ...

More Reading on Software engineering

• Software Engineering
• Dependency Injection
• User Experience and Front-End Engineering
• Usefulness of Code Reviews
• The Physical Effects of Working on Projects
• Do you need a University Degree for a Software Engineering Position
• Banning the Word Just and Should
• Value Objects in PureMVC and Object Naming Conventions
• Debugger vs System.out.println()
• Open Closed Principle in Object Oriented Programming
• Classic Mistakes in Software Engineering
• The Problem With Null