17 ms·

Dependency Injection is Evil (2011)

75 points by paralelogram 12y ago

hoodoof 12y ago
Really thoughtful, clearly articulated, backed with facts and diagrams, whining.
benvan 12y ago
I would argue that "dependency injection" at its purist is little more than the side-effect of designing with intent to minimise module responsibility. When writing a class, as a rule of thumb I'd posit there's a general advantage to outsourcing units of behaviour or complexity to other modules. Those other modules could be constructed by the class itself, but this is likely to make the current class concerned with the construction details of those modules. One of the simplest things to do, for example, is to ask for those modules to be provided to the class on construction. This sounds like a great idea until somebody comes along and calls it "dependency injection" and a bunch of us lose our minds.
- sparkie 12y ago
  Fowler has a habit of inventing "special terms" for what people have long considered "programming", and people get sucked into some fundamentalism. I don't like how the author of this article appeals to authority when trying to justify the use of a service locator over DI. > So if Martin Fowler says that it is possible to use a service locator instead of DI in unit testing, then who are you to argue otherwise? This argument is the same as "It is possible to use a global variable instead of an argument when unit testing a procedure." That's really what a service locator is - a facade around global variables, unless of course, you use DI to inject the service locator, then you've not really gained anything, but just inserted another layer of indirection. And that brings us back to why we even use techniques which are now labeled "DI" in the first place - they're basically there to avoid the use of globals (and hence, tight coupling). Interfaces are in place to keep implementations decoupled while providing everything necessary for them to interact.
  - sago 12y ago
    I see this argument pop up from time to time and it confuses me. It's almost as if someone read "global variables are evil" and understood it to mean "global data is evil". Singletons aren't global variables. Neither are service locators. Nor databases. Nor screens. Nor keyboards. Global variables are global variables. Unless they all are. And if you're going that way, you have a single main function, somewhere.
    - kaens 12y ago
      When people are referring to global variables these days, they would often be more accurate in referring to "global mutable state". Singletons can be this, service locators can be this, databases can be this. This can be bad, notably when assumptions are made about the state without taking into account that you're not the only one that could be changing it. Depending on what's changing, this can lead to very confusing / seemingly unpredictable behavior. Another way to put it is that the nature of the issue with "global variables" is often present in the things you mention.
      - Silhouette 12y ago
        I agree with your basic point, but I'm not sure you even need the mutability requirement to capture one of the underlying issues: you have an implicit dependency on something elsewhere in the system. Even if that something is constant, or at least constant during any particular program run, it still means you can't change the code that sets it up without checking your entire code base for unintended consequences. From this point of view, mutability just makes an existing fundamental problem worse, though it introduces new problems as well.
        sago 12y ago
        Why is it implicit? The point is that it is much more explicit. And use of SL doesn't create a dependency that isn't there otherwise. The dependency will be there anyway, because bits of code do depend on one another. The point is, do you want those dependencies to be managed by another piece of code and another piece of configuration? Or is it better to say what you need in the code where you need it? I'm not religious about it, there are times when being implicit is better, but often it is dramatically more complex for no obvious benefit.
- jblow 12y ago
  Yeah. I only heard about "dependency injection" a few months ago, and my reaction was that my brain just didn't get it, because, like, why are you making a huge deal about such a simple thing? If we made this much of a big deal out of every idea in programming, we would never be able to get anything done. Since then I keep hearing about "Dependency Injection" so my impression is that it's gaining in popularity. But my kneejerk reaction is always that if someone is talking about this subject, they probably are not a very good programmer, just like if someone is talking about how important UML diagrams are. It is maybe a hasty conclusion but that is where my brain goes.
  - sk5t 12y ago
    Good use of DI can help one write a more comprehensible, lighter, more flexible system, where each class is responsible for doing just one or two reasonably-scoped tasks. Unlike, say, an obsession with UML, DI is _not_ the hallmark of a crap-grade programmer. Nor is it all that simple, in the sense that it can transform your way of thinking about runtime configuration and object lifecycle management, and promotes a more flexible mindset. That said, I absolutely despise autowiring and annotation-based DI...
    - nulltype 12y ago
      Could you provide a concrete example of a good use of DI?
      - sk5t 12y ago
        In Java-land, let's say you have a class that depends on a micro-ORM library (or just a database connection, or whatever); the micro-ORM depends on a database connection, which might be yielded by a datasource, which in turn might be wrapped by a bounded connection pool. DI lets you push all that stuff to configuration rather than wiring it up in code; it reduces drag during development because you can always say, ah, I don't need to think about how or where the micro-ORM boots up, I can tune it later... I can even share the connection pool across five different consumers that are not aware of each other and share no compile-time dependency.
_throwmaybe_ 12y ago
There is a good reason to force people to use dependency injection. At least you're sure that their code will use an interface to describe a dependency which is a huge advantage compared to letting everybody write their own code as they want.
- kaens 12y ago
  The issue with this, in my experience, is that if you don't understand the driving principles behind DI patterns (prefer to depend on an interface or set of behaviors, prefer to be given something that satisfies that dependency instead of instantiating it yourself, with the aim of not doing things you aren't responsible for), you can end up with what amounts to either rather messy global state, or with systems that are still very highly coupled but have good paint. I can't help but see discussions about DI as suffering from sounding fancier than it is and also from less-experienced devs thinking that they must be writing "correct" code because it has the general shape of the DI pattern they read about. If it were my choice, I'd ditch the terminology and best practices all together in favor of active practice critically thinking about the dependencies, responsibilities, and assumptions of code being written or read.
jdpanderson 12y ago
A colleague and I had a discussion about this particular author. The conclusion was that he's an older programmer that doesn't like when the technology changes/evolves. Anything new is EVIL, and sometimes the people evolving the technology get slandered in the process. This is visible in this and many of his other articles. Edit: shouldn't have used the word "older". It has nothing to do with it. He's a programmer that doesn't like when technology changes/evolves.
- LoSboccacc 12y ago
  He has a point. For most uses I see of DI, a service locator would have been better. I think that some framework got too far with DI, especially those where a dependency is managed in a file which cannot be debugged or overloaded (i.e. spring with xml). As long as DI is used to decouple services, that's seems fine to me. Decoupling object in the dm hover seems overkill - like in the sample, where the address is injected on the person class. That rarely makes sense
- aikah 12y ago
  > he's an older programmer I don't think that has anything to do with age. Adaptation or Learning might be harder as you get old, yet you can find as much young developers that stick with things they know and refuse to learn or use new stuff. The whole "no framework" movement for instance in front-end development, "because frameworks are too complex". I doubt older developers prefer writing everything from scratch because framework X or Y requires reading the docs. Everybody has opinions on things, even younger developers write "rants" like that.
barrkel 12y ago
I have some sympathy for the idea that DI is harmful to good software design, but this article isn't an argument for it. My specific issue is that DI, and a number of other things, including single-implementation interfaces and mocks in testing, are normally used as a means to an end: testable fragments of code. Individually testable fragments of code, taken to its logical conclusion, converts every function into a class, possibly implementing an interface, and taking dependencies (i.e. the other methods it calls) as instance arguments, either directly to the method, or as arguments to the constructor (in a kind of OO partial application). You then end up with an atomized library of classes with names like ThingDoer and methods like doTheThing(). All the methods are now testable in isolation, since you can mock all the dependencies, and there's no risk of any pesky static references reaching out and pulling in stuff you can't easily mock. Splitting everything up so aggressively means that somebody now needs to put all the pieces back together. Some automated help (DI, IoC) is used. That's where the DI comes in. Some of the problems created by this style: * Cognitive overload: turning every dependency into a pluggable modularization point greatly inflates the number of concepts required to understand the code, especially from outside a library, because all the subcomponent parts all too often end up in the same namespace as the outer coordinating parts. * Far harder to understand without debug stepping: runtime composition of code and extra levels of indirection impede IDE code navigation - go to definition on a method, and you find out it's actually just on an interface, then you have to look up the class hierarchy, find the concrete implementation - only one if you're lucky - before you can trace things through. * Over-modularization / over-abstraction: since the code is split up into so many tiny bits, there's an illusion that reuse or modification of the code is possible by simply adding an extra implementation of one of the single-implementation interfaces. But extensibility needs to be designed in; pervasive, mandatory abstraction boundaries are unlikely to be good fits for ad-hoc future extension. * Brittle tests: because module boundaries go all the way down, and are individually tested, a refactoring that modifies the implementation of a library is made far more painful. Slightly chunkier tests - not quite integration, but unit-testing at the library level, the semantics that library clients actually care about - go a long way to reduce this. But once you go in this direction, the whole reason for the edifice's existence - individually unit-testable atoms of code - is called into question. This is also my problem with mainstream Java code style. My preferred style is to write support libraries that are individually testable at a slightly higher level, or are functional-style static methods that are generic and wholly testable with simple stubs, and write the main business code such that it uses the libraries in a fashion that's they're close to obviously correct as possible. Isolate any complicated logic into a testable functional static method, or a testable general (but not necessarily complete) library. Then integration-test this higher-level business logic. A common problem I see with many junior Java devs is that they write effectively procedural code split into method-per-class classes, and they zip together business logic and more complex implementation logic alongside one another. Rather than building abstractions that make their business logic simple and free of complex implementation, you end up with a procedural call tree that has a gestalt - the complex implementation - spread across and intermixed with business logic, and all of it tied together via indirected runtime composition, because testing. That's fairly abstract, so I'll make it concrete. Consider a spreadsheet report generator over data coming from entities in a database. Using a spreadsheet library (e.g. Apache POI) is typically quite thorny because it needs to try and support all the features, so you end up with complex logic dealing with each master row, then other methods that have complex logic dealing with each detail row. Code that has detailed knowledge about the business domain is intermixed with code that has detailed knowledge about the spreadsheet library's model. Let's not even talk about tests. An alternative approach - and a refactoring I made - was to create a reporting-oriented write-only facade for the spreadsheet manipulation. The business logic was then conflated from multiple complex classes to a single simple class that had straightforward code using the spreadsheet writer.
nicksellen 12y ago
The conclusion is a lot more moderate than the title, the author actually uses dependency injection: While DI has benefits in some circumstances, such as shown in the Copy program, I do not believe in the idea that it automatically provides benefits in all circumstances. This is why I consider that the application of DI in the wrong circumstances should be considered as being evil and not a universal panacea or silver bullet. In fact, in the wrong circumstances it could even be said that Dependency Injection breaks encapsulation. Although I have found some places in my framework where I have made use of DI because of the obvious benefits it provides, there are some places where I could use DI but have chosen not to do so. I think using the word evil is far too dramatic, evil should mean do not ever use.
- BurningFrog 12y ago
  So all he's saying is that using DI wrong is wrong?
- xtrumanx 12y ago
  Well at least he didn't title it "Dependency Injection Considered Harmful".
  - jschwartzi 12y ago
    Articles Titled Considered Harmful Considered Harmful
twa927 12y ago
I think things like dependency injection popularity can be explained by looking at communities created around programming languages. Particularly, the levels of abstraction a given community encourages is largely constant. Java is probably the leader in the amounts and levels of abstraction it's community uses. J2EE's EJB are a thing of the past, nowadays it's IC. And PHP for a long time is battling it's inferiority complex by imitating "serious" Java. I'm not saying that using a lot and deep abstractions is necessarily bad. You can write programs with the same functionality using different levels of it. What I'm saying that discussions like that are more "cultural wars" and there's no rational proof what's better.
PaulHoule 12y ago
I dunno. I write a lot of scripty programs that make subjective decisions that, when they work well enough, go into production. Consistent use of DI means that I never check my AWS keys into my source code. In particular I can do experiments that change out any module without having to touch the source code and that is pretty important.
awinder 12y ago
From the post: I do not use mock objects when building my application, and I do not see the sense in using mock objects when testing. If I am going to deliver a real object to my customer then I want to test that real object and not a reasonable facsimile This is because it would be so easy to put code in the mock object that passes a particular test, but when the same conditions are encountered in the real object in the customer's application the results are something else entirely. You should be testing the code that you will be delivering to your customers, not the code which exists only in the test suite. I don't think the argument for unit testing is that you should ONLY do unit testing. By stubbing/mocking and removing dependent systems from unit tests, you're usually left with: 1. Tests that run very well in isolation 2. Tests that run very quickly 3. Tests that are very stable (as long as the code isn't changing, results shouldn't change from run to run) All of these are great qualities for tests that will help you, the developer, continue to safely refactor code as your application ages. Functional tests where you're not stubbing / mocking will help you ensure your application continues to function as expected from a user interface perspective. Both are valuable to different audiences and for different purposes :-).
- jonhohle 12y ago
  I agree. I like take an onioned approach to software quality: * unit tests * release consistency (build artifacts and dependencies tracked as an atomic, reproducible unit) * some type of deployment/startup sanity tests * development environment integration tests * staging environment integration tests * statistical anomaly detection on one production box * application and infrastructure metric monitoring This is not a prescriptive list; just something I've found works well for continually deployed systems.
- DoggettCK 12y ago
  Agreed. Also, I'm pretty sure one of, if not the main point(s) of mocking is "How does this unit of code respond if an external dependency returns bad data?"
- mpweiher 12y ago
  Why I don't mock: http://blog.metaobject.com/2014/05/why-i-don-mock.html http://blog.metaobject.com/2014/05/why-i-don-mock.html Dependency Injection is a Virtue: http://blog.metaobject.com/2013/01/dependency-injection-is-virtue.html http://blog.metaobject.com/2013/01/dependency-injection-is-v...
spion 12y ago
What is evil in our profession is that everyone professes some technique or another that has worked for them, without mentioning any specifics about the exact situation in which that technique worked. Infact most programers go out of their ways to avoid mentioning specific experiences, confident that their grand designs generalize across all projects, platforms and languages. Just look up the recent TDD debate with Bob Martin and DHH and see if anyone mentioned one specific project / example. As a result we end up with long diatribes of barely useful "best practice" advice that is spread by means of cargo-culting and that causes problems down the line. What we need to collectively do is get off our high horses and start talking about specific projects, situations and problems. Start asking ourselves: Why did our solution work? What was the specific problem and situation? Which properties of the problem made our solution the right one?
BobTheCoder 12y ago
- DI doesn't add a lot of overhead. You don't really explain where it is EVIL, just that it is NOT STRICTLY NECESSARY ALL THE TIME. - It handles complex cases such as dependency X should be a singleton, or inserting a layer of caching in front of dependency Y. - It handles cases where dependency Z requires runtime logic to determine which implementation to use. You can do things like in PerformanceCriticalPackage use the HighPerformanceLogger and use some other logger else where. Want to switch these around, only need to touch the DI wiring logic. - I find it keeps modules that use other modules "cleaner" without having any kind of dependency construction logic in them. > Design patterns are an option, not a requirement Using in DI is a design pattern and I agree all usage of design patterns need to be justified. However not using DI and manually creating dependencies is ALSO a design pattern! You need to justify using either, or something different. Of the available options, using DI is generally the safest bet, especially if you want consistency throughout an application, since it's likely you will want this power somewhere.
_pmf_ 12y ago
I'm not sure whether this whole article is just an elaborate troll or if the author has never worked on anything but the greenest of greenfield applications. DI is not a pattern. The argument that DI breaks encapsulation does not make any sense at all; in fact, it's an argument in favor of DI, since it cleanly allows configurable behavior (the alternative requiring some way of configuring the host object to behave in a certain way using constructor arguments or setters). Dependency injection is a direct application of coding to interfaces instead of implementations (or to abstractions). In the absence of polymorphic constructions, the only way to achieve this is to either inject the dependency or a factory for the dependency.
elchief 12y ago
Mr. Marsten is the type of writer / programmer I dislike. Brevity is the soul of wit. Here's a summary: Dependency injection's primary benefit is to aid unit testing.
- pan69 12y ago
  Which makes Dependency Injection all the worth while using but since the Author doesn't Unit Test, the application of DI is obviously lost on him. So, big rant follows.
slakr 12y ago
> I could not let the arrogant statements in Ralph's article pass without comment, so I posted a reply. This was initially passed by the moderator, but was removed 24 hours later. It seems that some OO "purist" objected most strongly to my heretical viewpoint and had my comment removed. This I take as a form of censorship and a violation of my right to free speech. I love how people think they have a "right" to free speech on SOMEONE ELSE'S PLATFORM
ane 12y ago
"If you know you will never change the implementation or configuration of some dependency, there is no benefit in using dependency injection.". It all boils down to this. Here's the catch, though: with dependencies, it is really, really hard to know whether dependency implementations change or not. What is more, in most languages, implementing dependency injection is so trivial that it is always worth it. Conversely, the work associated with changing implementations that aren't built with some form of loose coupling, that is, designing around DI, is in most cases non-trivial.
- jblow 12y ago
  Nope. Nope nope. This is the same argument that early OO people used to justify the idea that you should use getter/setters everywhere rather than directly accessing your variables. You never know if the implementations of those ideas will change!!!!!11 That's programming. It is always possible that anything might need to change. That is how it is. This does not justify calcifying your code by adding extra unnecessary structure, because what that in fact does is make the program harder to change later (while requiring you to do more work up front). Also, as the author of the article notes, it requires one to keep more pieces of information clear in one's head in order to work with code of equivalent complexity, something that is almost always a big lose. In a good language, if a dependency implementation changes, you know this because your program does not compile. (Well, of course because you are not a noob, you are linking things that are versioned in the first place, so this should not ever even be an issue unless you are actively upgrading outside code and are expecting it.) When your program does not compile, you want the compile error to be at the site that uses the dependency, because that tells you exactly where the thing is that you need to fix. Adding excess verbiage around it, and distancing the site that instantiates the dependency from the site that uses it, only causes more work. If you are using a language/system that doesn't allow you to program this directly and clearly, then maybe that is the problem...
  - ane 12y ago
    It seems to me that you think designing for DI is much more complicated than it actually is. In most modern languages it is trivial to implement. Especially if you have ad-hoc polymorphism available, it comes at virtually no price. Some languages make it more difficult than others, but in most modern languages it's really easy. Your example of getters and setters is a bit of a red herring. I understand what you mean by it, but it doesn't apply in this case. This is because the getter and setter is an abstraction that derives from encapsulation. But it is also an antipattern. In many cases, getters and setters are just a type of needless complexity--a distraction, overengineering! On the other hand, DI solves a real, practial problem, and if your language is intelligent, it is really simple to implement.
KyeRussell 12y ago
> Those statements imply that if you are not using Dependency Injection (DI) then you are not doing OO "properly", that you are an idiot. I take great exception to that arrogant, condescending attitude. Stuff like this makes me question if this guy has some deeper issues he needs to work out before he can write blog posts about design patterns. The entire thing reeks of clickbait and narcissism.
pornel 12y ago
The article is overly dramatic about DI. Parts of it sound like a mere "get off my lawn!" rant against OOP in general (godwinning just few paragraphs in). There's praise for the Singleton antipattern, variables with an "obj" prefix as if objects were an odd thing to watch out for. There's an example of polymorphism achieved by setting a global variable before including a script. PHP (v4!) written like that would be icky even in 2011. There is some good advice in there too, but overall design it advocates for seems to reduce OOP to mere namespacing of global variables and functions. I'm assuming the author doesn't use unit tests either (given that TDD is "poppycock!"). It's not surprising that DI doesn't fit that way of building programs, but I don't think that makes DI evil. It's just a tool for a different job.
shadowmint 12y ago
> I do not believe in the idea that it automatically provides benefits in all circumstances Where 'it' is dependency injection, or, hey, anything else. How about we have an interesting conversation instead of rethrashing a stupid one (here is my straw man: 'you use DI for everything without thinking.' Watch as a bash it...)? Why do dynamic languages like python, ruby and javascript typically not use dependency injection? You could argue that some of them (python) don't have a great unit testing background, but modern projects like node do, and you still don't see the DI pattern thrown around a lot. In fact, you tend to only see it in languages that implement a native interface-based polymorphism, like java, c++ and c#. Even folks using go (http://openmymind.net/Dependency-Injection-In-Go/ http://openmymind.net/Dependency-Injection-In-Go/). Maybe rust too, but since the single ownership makes singletons an anti-pattern in rust, maybe not (at least I haven't seen it). Could it be you can get by just fine for all your testing needs without DI?
- rjbwork 12y ago
  Dynamic languages provide their own DI facilities simply by making objects. Since the definition of a class, or object, or prototype (whatever your language happens to call it) can be completely changed at runtime before ever getting to your code,there's no need for injection. You can simply configure all your services and helpers and config objects and managers etc. at startup, so there's no need for an explicit DI/IoC type pattern.
- arielby 12y ago
  Rust is new here, but it often does its dependency injection on the type-level (see the *_traits crates in servo, or anything involving piston - `https://github.com/piston-developers` https://github.com/piston-developers`). However, Rust doesn't have an OOP or Unit Test culture, so dependency injection is limited to true dependencies.
kazinator 12y ago
Let's look at Dependency Injection using a functional analogy. Imagine you wrote a function "add1" which adds 1 to every element of a list and returns a new list. This is inferior because it has a hard-coded dependency on the specific function object (lambda (arg) (+ 1 arg)). The dependency inversion way is to write a function "map" which is "configured" by taking a functional argument. Then you call (map (lambda (arg) (+ 1 arg)) ...) if you want to add 1 to every element, but of course you can use other functions. Now if we actually read the source code of this map, it is confusing compared to the code of add1. "What does this do? It calls the function that is passed in, but that could be anything! Why can't this damn thing just call a specific function? All this program ever needs is to add 1 to a list; why build this whole useless pattern?"
keredson 12y ago
Yes it is. One of the many reasons I've migrated away from the Java world. (There are no non-spring/non-hibernate jobs left!) Years ago I wrote a "get me the hell out of spring" tool: https://code.google.com/p/unsprung/ https://code.google.com/p/unsprung/
- eropple 12y ago
  I've literally never worked at a Java shop that used Spring or Hibernate. There's plenty of such places (I mean, just look at "anybody using Dropwizard").
keredson 12y ago
Yes it is. One of the many reasons I've migrated away from the Java world. (There are no non-spring/non-hibernate jobs left!) Years ago I wrote a "get me the hell out of spring" tool: https://code.google.com/p/unsprung/ https://code.google.com/p/unsprung/
dicroce 12y ago
DI is a good and useful thing, but like a lot of fads in software development it is being overused in some places... Actually what DI brings to mind for me is functional programming. By injecting your dependencies (as opposed to simply constructing them) you are moving your code just slightly in the functional direction. This brings many well known benefits, but also its own costs.
pohl 12y ago
I suspect that — late at night, tucked in for a slumber after toiling all day in the processor — injected dependencies dream they are first class functions, their service interfaces dream they are function signatures, and the objects into which they are injected dream of being curried functions to which some dependency arguments have already been partially applied.
- arielby 12y ago
  Except that an interface's signature is more complicated than a single function.
  - yebyen 12y ago
    > their service interfaces dream they are function signatures In Go, at least, an interface is nothing more than a collection of function signatures (with the type Foo interface{...} wrapped around them, they become the interface known as Foo.)
oldmanjay 12y ago
this article is awful. insecurity theater, lots of wiki copy-paste, and a fundamental misunderstanding of testing object oriented systems. maybe this was meant to be humorous?
V-2 12y ago
I do not use mock objects when building my application, and I do not see the sense in using mock objects when testing. If I am going to deliver a real object to my customer then I want to test that real object and not a reasonable facsimile This reveals a fundamental misunderstanding of the purpose of mocking. If I test object A (and mock B for this purpose), I'm testing A - not the mock. Another test verifies behavior of concrete object B (while mocking A). Mocks themselves are not what is being tested. Of course it is possible that both A and B behave correctly in isolation (measured against expectations defined by unit tests), but they don't integrate well. In other words, expectations, assumptions verified by both unit test suites do not cover everything that's actually required for the components to form a functional system - there is a "gap". This is however not a flaw of Dependency Injection, but a natural shortcoming of unit tests as such. Obviously they are not a replacement for integration tests - but that works both ways. Different beasts. The advantage that unit tests have over integration tests is that they make it much easier to pinpoint sources of failures.

75 points by paralelogram 12y ago

Really thoughtful, clearly articulated, backed with facts and diagrams, whining.

I would argue that "dependency injection" at its purist is little more than the side-effect of designing with intent to minimise module responsibility. When writing a class, as a rule of thumb I'd posit there's a general advantage to outsourcing units of behaviour or complexity to other modules. Those other modules could be constructed by the class itself, but this is likely to make the current class concerned with the construction details of those modules. One of the simplest things to do, for example, is to ask for those modules to be provided to the class on construction. This sounds like a great idea until somebody comes along and calls it "dependency injection" and a bunch of us lose our minds.

sparkie 12y ago
Fowler has a habit of inventing "special terms" for what people have long considered "programming", and people get sucked into some fundamentalism. I don't like how the author of this article appeals to authority when trying to justify the use of a service locator over DI. > So if Martin Fowler says that it is possible to use a service locator instead of DI in unit testing, then who are you to argue otherwise? This argument is the same as "It is possible to use a global variable instead of an argument when unit testing a procedure." That's really what a service locator is - a facade around global variables, unless of course, you use DI to inject the service locator, then you've not really gained anything, but just inserted another layer of indirection. And that brings us back to why we even use techniques which are now labeled "DI" in the first place - they're basically there to avoid the use of globals (and hence, tight coupling). Interfaces are in place to keep implementations decoupled while providing everything necessary for them to interact.
- sago 12y ago
  I see this argument pop up from time to time and it confuses me. It's almost as if someone read "global variables are evil" and understood it to mean "global data is evil". Singletons aren't global variables. Neither are service locators. Nor databases. Nor screens. Nor keyboards. Global variables are global variables. Unless they all are. And if you're going that way, you have a single main function, somewhere.
  - kaens 12y ago
    When people are referring to global variables these days, they would often be more accurate in referring to "global mutable state". Singletons can be this, service locators can be this, databases can be this. This can be bad, notably when assumptions are made about the state without taking into account that you're not the only one that could be changing it. Depending on what's changing, this can lead to very confusing / seemingly unpredictable behavior. Another way to put it is that the nature of the issue with "global variables" is often present in the things you mention.
    - Silhouette 12y ago
      I agree with your basic point, but I'm not sure you even need the mutability requirement to capture one of the underlying issues: you have an implicit dependency on something elsewhere in the system. Even if that something is constant, or at least constant during any particular program run, it still means you can't change the code that sets it up without checking your entire code base for unintended consequences. From this point of view, mutability just makes an existing fundamental problem worse, though it introduces new problems as well.
      - sago 12y ago
        Why is it implicit? The point is that it is much more explicit. And use of SL doesn't create a dependency that isn't there otherwise. The dependency will be there anyway, because bits of code do depend on one another. The point is, do you want those dependencies to be managed by another piece of code and another piece of configuration? Or is it better to say what you need in the code where you need it? I'm not religious about it, there are times when being implicit is better, but often it is dramatically more complex for no obvious benefit.
jblow 12y ago
Yeah. I only heard about "dependency injection" a few months ago, and my reaction was that my brain just didn't get it, because, like, why are you making a huge deal about such a simple thing? If we made this much of a big deal out of every idea in programming, we would never be able to get anything done. Since then I keep hearing about "Dependency Injection" so my impression is that it's gaining in popularity. But my kneejerk reaction is always that if someone is talking about this subject, they probably are not a very good programmer, just like if someone is talking about how important UML diagrams are. It is maybe a hasty conclusion but that is where my brain goes.
- sk5t 12y ago
  Good use of DI can help one write a more comprehensible, lighter, more flexible system, where each class is responsible for doing just one or two reasonably-scoped tasks. Unlike, say, an obsession with UML, DI is _not_ the hallmark of a crap-grade programmer. Nor is it all that simple, in the sense that it can transform your way of thinking about runtime configuration and object lifecycle management, and promotes a more flexible mindset. That said, I absolutely despise autowiring and annotation-based DI...
  - nulltype 12y ago
    Could you provide a concrete example of a good use of DI?
    - sk5t 12y ago
      In Java-land, let's say you have a class that depends on a micro-ORM library (or just a database connection, or whatever); the micro-ORM depends on a database connection, which might be yielded by a datasource, which in turn might be wrapped by a bounded connection pool. DI lets you push all that stuff to configuration rather than wiring it up in code; it reduces drag during development because you can always say, ah, I don't need to think about how or where the micro-ORM boots up, I can tune it later... I can even share the connection pool across five different consumers that are not aware of each other and share no compile-time dependency.

_throwmaybe_ 12y ago

There is a good reason to force people to use dependency injection. At least you're sure that their code will use an interface to describe a dependency which is a huge advantage compared to letting everybody write their own code as they want.

kaens 12y ago
The issue with this, in my experience, is that if you don't understand the driving principles behind DI patterns (prefer to depend on an interface or set of behaviors, prefer to be given something that satisfies that dependency instead of instantiating it yourself, with the aim of not doing things you aren't responsible for), you can end up with what amounts to either rather messy global state, or with systems that are still very highly coupled but have good paint. I can't help but see discussions about DI as suffering from sounding fancier than it is and also from less-experienced devs thinking that they must be writing "correct" code because it has the general shape of the DI pattern they read about. If it were my choice, I'd ditch the terminology and best practices all together in favor of active practice critically thinking about the dependencies, responsibilities, and assumptions of code being written or read.

jdpanderson 12y ago

A colleague and I had a discussion about this particular author. The conclusion was that he's an older programmer that doesn't like when the technology changes/evolves. Anything new is EVIL, and sometimes the people evolving the technology get slandered in the process. This is visible in this and many of his other articles. Edit: shouldn't have used the word "older". It has nothing to do with it. He's a programmer that doesn't like when technology changes/evolves.

LoSboccacc 12y ago
He has a point. For most uses I see of DI, a service locator would have been better. I think that some framework got too far with DI, especially those where a dependency is managed in a file which cannot be debugged or overloaded (i.e. spring with xml). As long as DI is used to decouple services, that's seems fine to me. Decoupling object in the dm hover seems overkill - like in the sample, where the address is injected on the person class. That rarely makes sense
aikah 12y ago
> he's an older programmer I don't think that has anything to do with age. Adaptation or Learning might be harder as you get old, yet you can find as much young developers that stick with things they know and refuse to learn or use new stuff. The whole "no framework" movement for instance in front-end development, "because frameworks are too complex". I doubt older developers prefer writing everything from scratch because framework X or Y requires reading the docs. Everybody has opinions on things, even younger developers write "rants" like that.

barrkel 12y ago

I have some sympathy for the idea that DI is harmful to good software design, but this article isn't an argument for it. My specific issue is that DI, and a number of other things, including single-implementation interfaces and mocks in testing, are normally used as a means to an end: testable fragments of code. Individually testable fragments of code, taken to its logical conclusion, converts every function into a class, possibly implementing an interface, and taking dependencies (i.e. the other methods it calls) as instance arguments, either directly to the method, or as arguments to the constructor (in a kind of OO partial application). You then end up with an atomized library of classes with names like ThingDoer and methods like doTheThing(). All the methods are now testable in isolation, since you can mock all the dependencies, and there's no risk of any pesky static references reaching out and pulling in stuff you can't easily mock. Splitting everything up so aggressively means that somebody now needs to put all the pieces back together. Some automated help (DI, IoC) is used. That's where the DI comes in. Some of the problems created by this style: * Cognitive overload: turning every dependency into a pluggable modularization point greatly inflates the number of concepts required to understand the code, especially from outside a library, because all the subcomponent parts all too often end up in the same namespace as the outer coordinating parts. * Far harder to understand without debug stepping: runtime composition of code and extra levels of indirection impede IDE code navigation - go to definition on a method, and you find out it's actually just on an interface, then you have to look up the class hierarchy, find the concrete implementation - only one if you're lucky - before you can trace things through. * Over-modularization / over-abstraction: since the code is split up into so many tiny bits, there's an illusion that reuse or modification of the code is possible by simply adding an extra implementation of one of the single-implementation interfaces. But extensibility needs to be designed in; pervasive, mandatory abstraction boundaries are unlikely to be good fits for ad-hoc future extension. * Brittle tests: because module boundaries go all the way down, and are individually tested, a refactoring that modifies the implementation of a library is made far more painful. Slightly chunkier tests - not quite integration, but unit-testing at the library level, the semantics that library clients actually care about - go a long way to reduce this. But once you go in this direction, the whole reason for the edifice's existence - individually unit-testable atoms of code - is called into question. This is also my problem with mainstream Java code style. My preferred style is to write support libraries that are individually testable at a slightly higher level, or are functional-style static methods that are generic and wholly testable with simple stubs, and write the main business code such that it uses the libraries in a fashion that's they're close to obviously correct as possible. Isolate any complicated logic into a testable functional static method, or a testable general (but not necessarily complete) library. Then integration-test this higher-level business logic. A common problem I see with many junior Java devs is that they write effectively procedural code split into method-per-class classes, and they zip together business logic and more complex implementation logic alongside one another. Rather than building abstractions that make their business logic simple and free of complex implementation, you end up with a procedural call tree that has a gestalt - the complex implementation - spread across and intermixed with business logic, and all of it tied together via indirected runtime composition, because testing. That's fairly abstract, so I'll make it concrete. Consider a spreadsheet report generator over data coming from entities in a database. Using a spreadsheet library (e.g. Apache POI) is typically quite thorny because it needs to try and support all the features, so you end up with complex logic dealing with each master row, then other methods that have complex logic dealing with each detail row. Code that has detailed knowledge about the business domain is intermixed with code that has detailed knowledge about the spreadsheet library's model. Let's not even talk about tests. An alternative approach - and a refactoring I made - was to create a reporting-oriented write-only facade for the spreadsheet manipulation. The business logic was then conflated from multiple complex classes to a single simple class that had straightforward code using the spreadsheet writer.

nicksellen 12y ago

The conclusion is a lot more moderate than the title, the author actually uses dependency injection: While DI has benefits in some circumstances, such as shown in the Copy program, I do not believe in the idea that it automatically provides benefits in all circumstances. This is why I consider that the application of DI in the wrong circumstances should be considered as being evil and not a universal panacea or silver bullet. In fact, in the wrong circumstances it could even be said that Dependency Injection breaks encapsulation. Although I have found some places in my framework where I have made use of DI because of the obvious benefits it provides, there are some places where I could use DI but have chosen not to do so. I think using the word evil is far too dramatic, evil should mean do not ever use.

BurningFrog 12y ago
So all he's saying is that using DI wrong is wrong?
xtrumanx 12y ago
Well at least he didn't title it "Dependency Injection Considered Harmful".
- jschwartzi 12y ago
  Articles Titled Considered Harmful Considered Harmful

twa927 12y ago

I think things like dependency injection popularity can be explained by looking at communities created around programming languages. Particularly, the levels of abstraction a given community encourages is largely constant. Java is probably the leader in the amounts and levels of abstraction it's community uses. J2EE's EJB are a thing of the past, nowadays it's IC. And PHP for a long time is battling it's inferiority complex by imitating "serious" Java. I'm not saying that using a lot and deep abstractions is necessarily bad. You can write programs with the same functionality using different levels of it. What I'm saying that discussions like that are more "cultural wars" and there's no rational proof what's better.

PaulHoule 12y ago

I dunno. I write a lot of scripty programs that make subjective decisions that, when they work well enough, go into production. Consistent use of DI means that I never check my AWS keys into my source code. In particular I can do experiments that change out any module without having to touch the source code and that is pretty important.

awinder 12y ago

From the post: I do not use mock objects when building my application, and I do not see the sense in using mock objects when testing. If I am going to deliver a real object to my customer then I want to test that real object and not a reasonable facsimile This is because it would be so easy to put code in the mock object that passes a particular test, but when the same conditions are encountered in the real object in the customer's application the results are something else entirely. You should be testing the code that you will be delivering to your customers, not the code which exists only in the test suite. I don't think the argument for unit testing is that you should ONLY do unit testing. By stubbing/mocking and removing dependent systems from unit tests, you're usually left with: 1. Tests that run very well in isolation 2. Tests that run very quickly 3. Tests that are very stable (as long as the code isn't changing, results shouldn't change from run to run) All of these are great qualities for tests that will help you, the developer, continue to safely refactor code as your application ages. Functional tests where you're not stubbing / mocking will help you ensure your application continues to function as expected from a user interface perspective. Both are valuable to different audiences and for different purposes :-).

jonhohle 12y ago
I agree. I like take an onioned approach to software quality: * unit tests * release consistency (build artifacts and dependencies tracked as an atomic, reproducible unit) * some type of deployment/startup sanity tests * development environment integration tests * staging environment integration tests * statistical anomaly detection on one production box * application and infrastructure metric monitoring This is not a prescriptive list; just something I've found works well for continually deployed systems.
DoggettCK 12y ago
Agreed. Also, I'm pretty sure one of, if not the main point(s) of mocking is "How does this unit of code respond if an external dependency returns bad data?"
mpweiher 12y ago
Why I don't mock: http://blog.metaobject.com/2014/05/why-i-don-mock.html http://blog.metaobject.com/2014/05/why-i-don-mock.html Dependency Injection is a Virtue: http://blog.metaobject.com/2013/01/dependency-injection-is-virtue.html http://blog.metaobject.com/2013/01/dependency-injection-is-v...

spion 12y ago

What is evil in our profession is that everyone professes some technique or another that has worked for them, without mentioning any specifics about the exact situation in which that technique worked. Infact most programers go out of their ways to avoid mentioning specific experiences, confident that their grand designs generalize across all projects, platforms and languages. Just look up the recent TDD debate with Bob Martin and DHH and see if anyone mentioned one specific project / example. As a result we end up with long diatribes of barely useful "best practice" advice that is spread by means of cargo-culting and that causes problems down the line. What we need to collectively do is get off our high horses and start talking about specific projects, situations and problems. Start asking ourselves: Why did our solution work? What was the specific problem and situation? Which properties of the problem made our solution the right one?

BobTheCoder 12y ago

- DI doesn't add a lot of overhead. You don't really explain where it is EVIL, just that it is NOT STRICTLY NECESSARY ALL THE TIME. - It handles complex cases such as dependency X should be a singleton, or inserting a layer of caching in front of dependency Y. - It handles cases where dependency Z requires runtime logic to determine which implementation to use. You can do things like in PerformanceCriticalPackage use the HighPerformanceLogger and use some other logger else where. Want to switch these around, only need to touch the DI wiring logic. - I find it keeps modules that use other modules "cleaner" without having any kind of dependency construction logic in them. > Design patterns are an option, not a requirement Using in DI is a design pattern and I agree all usage of design patterns need to be justified. However not using DI and manually creating dependencies is ALSO a design pattern! You need to justify using either, or something different. Of the available options, using DI is generally the safest bet, especially if you want consistency throughout an application, since it's likely you will want this power somewhere.

_pmf_ 12y ago

I'm not sure whether this whole article is just an elaborate troll or if the author has never worked on anything but the greenest of greenfield applications. DI is not a pattern. The argument that DI breaks encapsulation does not make any sense at all; in fact, it's an argument in favor of DI, since it cleanly allows configurable behavior (the alternative requiring some way of configuring the host object to behave in a certain way using constructor arguments or setters). Dependency injection is a direct application of coding to interfaces instead of implementations (or to abstractions). In the absence of polymorphic constructions, the only way to achieve this is to either inject the dependency or a factory for the dependency.

elchief 12y ago

Mr. Marsten is the type of writer / programmer I dislike. Brevity is the soul of wit. Here's a summary: Dependency injection's primary benefit is to aid unit testing.

pan69 12y ago
Which makes Dependency Injection all the worth while using but since the Author doesn't Unit Test, the application of DI is obviously lost on him. So, big rant follows.

slakr 12y ago

> I could not let the arrogant statements in Ralph's article pass without comment, so I posted a reply. This was initially passed by the moderator, but was removed 24 hours later. It seems that some OO "purist" objected most strongly to my heretical viewpoint and had my comment removed. This I take as a form of censorship and a violation of my right to free speech. I love how people think they have a "right" to free speech on SOMEONE ELSE'S PLATFORM

ane 12y ago

"If you know you will never change the implementation or configuration of some dependency, there is no benefit in using dependency injection.". It all boils down to this. Here's the catch, though: with dependencies, it is really, really hard to know whether dependency implementations change or not. What is more, in most languages, implementing dependency injection is so trivial that it is always worth it. Conversely, the work associated with changing implementations that aren't built with some form of loose coupling, that is, designing around DI, is in most cases non-trivial.

jblow 12y ago
Nope. Nope nope. This is the same argument that early OO people used to justify the idea that you should use getter/setters everywhere rather than directly accessing your variables. You never know if the implementations of those ideas will change!!!!!11 That's programming. It is always possible that anything might need to change. That is how it is. This does not justify calcifying your code by adding extra unnecessary structure, because what that in fact does is make the program harder to change later (while requiring you to do more work up front). Also, as the author of the article notes, it requires one to keep more pieces of information clear in one's head in order to work with code of equivalent complexity, something that is almost always a big lose. In a good language, if a dependency implementation changes, you know this because your program does not compile. (Well, of course because you are not a noob, you are linking things that are versioned in the first place, so this should not ever even be an issue unless you are actively upgrading outside code and are expecting it.) When your program does not compile, you want the compile error to be at the site that uses the dependency, because that tells you exactly where the thing is that you need to fix. Adding excess verbiage around it, and distancing the site that instantiates the dependency from the site that uses it, only causes more work. If you are using a language/system that doesn't allow you to program this directly and clearly, then maybe that is the problem...
- ane 12y ago
  It seems to me that you think designing for DI is much more complicated than it actually is. In most modern languages it is trivial to implement. Especially if you have ad-hoc polymorphism available, it comes at virtually no price. Some languages make it more difficult than others, but in most modern languages it's really easy. Your example of getters and setters is a bit of a red herring. I understand what you mean by it, but it doesn't apply in this case. This is because the getter and setter is an abstraction that derives from encapsulation. But it is also an antipattern. In many cases, getters and setters are just a type of needless complexity--a distraction, overengineering! On the other hand, DI solves a real, practial problem, and if your language is intelligent, it is really simple to implement.

KyeRussell 12y ago

> Those statements imply that if you are not using Dependency Injection (DI) then you are not doing OO "properly", that you are an idiot. I take great exception to that arrogant, condescending attitude. Stuff like this makes me question if this guy has some deeper issues he needs to work out before he can write blog posts about design patterns. The entire thing reeks of clickbait and narcissism.

pornel 12y ago

The article is overly dramatic about DI. Parts of it sound like a mere "get off my lawn!" rant against OOP in general (godwinning just few paragraphs in). There's praise for the Singleton antipattern, variables with an "obj" prefix as if objects were an odd thing to watch out for. There's an example of polymorphism achieved by setting a global variable before including a script. PHP (v4!) written like that would be icky even in 2011. There is some good advice in there too, but overall design it advocates for seems to reduce OOP to mere namespacing of global variables and functions. I'm assuming the author doesn't use unit tests either (given that TDD is "poppycock!"). It's not surprising that DI doesn't fit that way of building programs, but I don't think that makes DI evil. It's just a tool for a different job.

shadowmint 12y ago

> I do not believe in the idea that it automatically provides benefits in all circumstances Where 'it' is dependency injection, or, hey, anything else. How about we have an interesting conversation instead of rethrashing a stupid one (here is my straw man: 'you use DI for everything without thinking.' Watch as a bash it...)? Why do dynamic languages like python, ruby and javascript typically not use dependency injection? You could argue that some of them (python) don't have a great unit testing background, but modern projects like node do, and you still don't see the DI pattern thrown around a lot. In fact, you tend to only see it in languages that implement a native interface-based polymorphism, like java, c++ and c#. Even folks using go (http://openmymind.net/Dependency-Injection-In-Go/ http://openmymind.net/Dependency-Injection-In-Go/). Maybe rust too, but since the single ownership makes singletons an anti-pattern in rust, maybe not (at least I haven't seen it). Could it be you can get by just fine for all your testing needs without DI?

rjbwork 12y ago
Dynamic languages provide their own DI facilities simply by making objects. Since the definition of a class, or object, or prototype (whatever your language happens to call it) can be completely changed at runtime before ever getting to your code,there's no need for injection. You can simply configure all your services and helpers and config objects and managers etc. at startup, so there's no need for an explicit DI/IoC type pattern.
arielby 12y ago
Rust is new here, but it often does its dependency injection on the type-level (see the *_traits crates in servo, or anything involving piston - `https://github.com/piston-developers` https://github.com/piston-developers`). However, Rust doesn't have an OOP or Unit Test culture, so dependency injection is limited to true dependencies.

kazinator 12y ago

Let's look at Dependency Injection using a functional analogy. Imagine you wrote a function "add1" which adds 1 to every element of a list and returns a new list. This is inferior because it has a hard-coded dependency on the specific function object (lambda (arg) (+ 1 arg)). The dependency inversion way is to write a function "map" which is "configured" by taking a functional argument. Then you call (map (lambda (arg) (+ 1 arg)) ...) if you want to add 1 to every element, but of course you can use other functions. Now if we actually read the source code of this map, it is confusing compared to the code of add1. "What does this do? It calls the function that is passed in, but that could be anything! Why can't this damn thing just call a specific function? All this program ever needs is to add 1 to a list; why build this whole useless pattern?"

keredson 12y ago

Yes it is. One of the many reasons I've migrated away from the Java world. (There are no non-spring/non-hibernate jobs left!) Years ago I wrote a "get me the hell out of spring" tool: https://code.google.com/p/unsprung/ https://code.google.com/p/unsprung/

eropple 12y ago
I've literally never worked at a Java shop that used Spring or Hibernate. There's plenty of such places (I mean, just look at "anybody using Dropwizard").

keredson 12y ago

dicroce 12y ago

DI is a good and useful thing, but like a lot of fads in software development it is being overused in some places... Actually what DI brings to mind for me is functional programming. By injecting your dependencies (as opposed to simply constructing them) you are moving your code just slightly in the functional direction. This brings many well known benefits, but also its own costs.

pohl 12y ago

I suspect that — late at night, tucked in for a slumber after toiling all day in the processor — injected dependencies dream they are first class functions, their service interfaces dream they are function signatures, and the objects into which they are injected dream of being curried functions to which some dependency arguments have already been partially applied.

arielby 12y ago
Except that an interface's signature is more complicated than a single function.
- yebyen 12y ago
  > their service interfaces dream they are function signatures In Go, at least, an interface is nothing more than a collection of function signatures (with the type Foo interface{...} wrapped around them, they become the interface known as Foo.)

oldmanjay 12y ago

this article is awful. insecurity theater, lots of wiki copy-paste, and a fundamental misunderstanding of testing object oriented systems. maybe this was meant to be humorous?

V-2 12y ago

I do not use mock objects when building my application, and I do not see the sense in using mock objects when testing. If I am going to deliver a real object to my customer then I want to test that real object and not a reasonable facsimile This reveals a fundamental misunderstanding of the purpose of mocking. If I test object A (and mock B for this purpose), I'm testing A - not the mock. Another test verifies behavior of concrete object B (while mocking A). Mocks themselves are not what is being tested. Of course it is possible that both A and B behave correctly in isolation (measured against expectations defined by unit tests), but they don't integrate well. In other words, expectations, assumptions verified by both unit test suites do not cover everything that's actually required for the components to form a functional system - there is a "gap". This is however not a flaw of Dependency Injection, but a natural shortcoming of unit tests as such. Obviously they are not a replacement for integration tests - but that works both ways. Different beasts. The advantage that unit tests have over integration tests is that they make it much easier to pinpoint sources of failures.