Dependency Injection is Evil (2011)
tonymarston.net
tonymarston.net
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?
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.
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)
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
Dependency Injection is a Virtue: http://blog.metaobject.com/2013/01/dependency-injection-is-v...
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.
> 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.
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.
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.
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.
Because if we have module A depending on module B via some clearly defined interface, but in fact the behaviour of module B also depends on global module C that is set up elsewhere, then B's interface no longer fully describes what A can expect.
If C's scope were limited to what's happening within B anyway then this would just be an implementation detail. If C were given to B as some form of explicit dependency by A, then it would be a specified part of the interface. However, if C effectively has global scope by any mechanism then there is now an implicit interface to change B's behaviour that A doesn't know about. Developers reading or maintaining the code for A, C, and anywhere else that can affect C if it's mutable, then need to be aware of what each other are doing, and changes to any of these parts of the code potentially affect any of the others.
(I'm not going to address your other point, because I didn't say anything about service locators in the first place.)
I don't think you do either, although if it's a globally accessible constant throughout a run, problems with inconsistencies only tend to crop up if the value is being used to determine behavior -- which you might need to check for, as you mention.
I'm not sure if global mutable state is the same as the problem you point out though -- they do share a similar nature in the framing of dependencies, but they cause problems for different reasons.
Also, mutability tends to be able to be a real problem in systems much smaller than ones where problems from abuse of global constants start to rear their heads.
I agree, there are (at least) two distinct problems here.
One is the existence of any implicit dependency because of global (or other broad) scope. This can create surprising spacial interactions in the code, making it harder to maintain.
Another is the existence of mutable state. This can create surprising temporal interactions in the code, also making it harder to maintain.
Loosely speaking, the danger from these effects multiplies.
Thus, if you have a program that has an immutable global constant it is likely in the same situation. How do you ever change that value in any way without retesting everything to see what the effect was?
I don't accept your premise.
Firstly, constants are used for all kinds of things, from hard mathematical data as in your example to configuring connectivity with external services via particular database details or URLs.
Secondly, while some programs really do only have one main purpose and so some of the background/context data really is almost globally applicable, this is certainly not always the case. In particular, the larger a software system becomes, the less likely this is to be true.
How do you ever change that value in any way without retesting everything to see what the effect was?
If the value doesn't have global scope, you don't have to retest everything, only parts of the system that can be affected by the change.
A database is a good example. One might have some class "Person" with some business related logic in it. If your goal is to simply test this business logic of a person, then why would your test be concerned about whether it can establish a connection to a database? By definition, this is no longer a unit test, but a systems test, and the test surface is much larger because now you need to be concerned about whether or not a connection can be established and myriad of other possible problems, all of which could be tested separately, and by knowing which tests succeed/fail, we can have immediate feedback on where some problems might exist, rather than having to debug an entire system to find an issue.
In the case of the service locator - you can't really perform "unit tests" on individual blocks of code which have dependency on the SL, because the SL is mutated in arbitrary places througout the codebase. The SL acts to increase coupling, because now instead of depending on just a specific interface, you depend on the whole runtime data of your application.
Strange, I thought it was terminology for global variables.
> What I mean by "globals" in the scope of testing is "side-effects"
Which is as whole different kettle of mackerel. Minimising side-effects is, of course, excellent advice, and can help with testing. But global variables and SL are not the same thing as side-effects.
Your example (of testing a database) seems very confused to me. You're talking about coupling now. Not global variables. Why would you suddenly need a database connection? Why does the existence of global mutable state mean that nothing in your code can be tested independently? You seem to be imagining the worst case of coupling as an argument against service lookup.
The last paragraph seems blatantly false. You're again straw manning this version of an SL that is mutated in arbitrary places through the code-base and therefore can't be tested in isolation, and neither can the components that use it. That is a strange version of SL you have here, and one that DI wouldn't help with.
They're examples of side effects. It's not good enough to set the values of a global variable or register some service purely for the purpose of a test, because the test then does not reflect the runtime behavior of the code. The benefit of a unit test is to assert that code behaves the same way all the time - not just for specific values you use at the time of testing.
> Your example (of testing a database) seems very confused to me. You're talking about coupling now. Not global variables. Why would you suddenly need a database connection? Why does the existence of global mutable state mean that nothing in your code can be tested independently? You seem to have a strange idea of how software works.
Global variables increase coupling - code which consumes a global variable now has a dependency on all of the code which mutates it. You simply cannot test the consuming code in isolation without regard for the code mutating the variable, unless your test is exhaustive of every possible value which the global variable may contain.
My example was not of testing a database, it was about testing algorithms or logic that might exist inside some class named "Person", but which has a data dependency on an actual person (held in a database). If one wants to test the logic only, then mock data must be supplied instead of the real data from the database - else you're not testing only the person, but also testing that the database is connected and querying it is successful. The correct way to test this is to decouple Person from the database, usually be means of a mock object, or by passing the mock data into the person directly. Either way, it seems the blog author does not do such unit tests, as he doesn't use mock objects.
> 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.
The problem with the author's philosophy is that it means when problems do arise in his applications, he must perform whole system testing/debugging to find them. He is missing perhaps the main benefit of unit tests - which is that, when a bug arises, you can quickly eliminate many possible causes because unit tests against those parts of code have succeeded (unless your unit tests were wrong to begin with, which will more or less be the case if they're testing against code which depends on globals).
Testing with a mock object implies that the mock object can generate all the required output that the real object can generate that might have some effect on the consuming code. Not only that, but it assumes that the mock object generates the correct data in ways that cannot generate false positives in the test. This doesn't mean you're only testing the client logic. You're now testing the client logic using services that are ad-hoc and aren't guaranteed to behave like the real thing. You're testing a fantasy.
It is far better to test against the real database. Using a fixture, or a transaction, or some way to use the actual system with representative data. Mocks have their place in very complex services where this is practically impossible. But they don't suddenly make things better for testing, or more atomic. IMHO, when you have to use a mock, it should be as a last resort, when you have to sacrifice fidelity for tractability. Your code is coupled in behavior to the services it uses, pretending it isn't is just fooling yourself.
I have very much the same problem with people who write unit tests against, say SQLite databases, rather than the full DBMS. The complexity of 'masking sure the database is connected and can be queried' is pretty trivial compared to the complexity of mocking a whole RBMDS interface. Good software engineering will, of course, limit the number of places the database interfaces with (I'm not suggesting code with SQL statements in strings everywhere, that's a straw man). But I'd not accept mocked tests that exists just to avoid a database connection or because the developer doesn't understand how to write a transaction.
So I don't understand. Either you're advocating a very bizarre, and seemingly pathological development style, or you're consistently muddying the waters by comparing good programming in your chosen methodology with bad programming in mine, which just misses the point.
Here's an example then. In your Person object, on a platform with reasonable transaction/fixtures support (like Django). Is it better to write your unit test using a mocked ORM layer, or a fixture with the test data in it?
> He is missing perhaps the main benefit of unit tests - which is that, when a bug arises, you can quickly eliminate many possible causes because unit tests against those parts of code have succeeded
I've no idea why this is somehow impossible. I write unit tests at various levels of abstraction. If I have module A, calling module B which calls module C, then I need tests for C, B(+C) and A(+B+C). If I get a failure in A, I make sure that there is a test in B that corresponds to the way A is using B, if so, it is a problem with A, not B. If B and C were mocked, I'd have no way of knowing if the problem was with the mock logic without having to test C, C-mock, B+C-mock, B-mock, A+B-mock.
> now has a dependency on all of the code which mutates it
This seems a bizarre claim. Does your code have a dependency on everything else that can possibly change what's on the screen? If so, how do you deal with that?
That's why pretending 'global variables' = 'all central resources' seems foolish to me.
If I were testing a salary calculation which takes values from a database, and I named my test "Test_salary_calculation_correct", where instead of using some sample data which could easily cover the range of values I need to test against, I instead relied on a database connection, and this test failed because the database was not accessible - I've only confused the developer who picks up my shit where "Test_salary_calculation_correct" fails, and he thinks there's a problem with my calculation rather than a misconfigured firewall somewhere else. The firewall has nothing to do with my salary calcuation - why should it have any effect on the test passing?
The way I see unit tests is this: If you write a test and it passes on your machine, then some other developer takes your code and the same test fails - it's a fuckup on your behalf. Unit tests should not depend on the environment in any way. Actually, by definition, a unit test is a test of a single "unit" - including database access into this is well beyond the scope of unit testing, but into integration testing.
To me it seems you're skipping unit testing and just going onto integration testing with your unit testing framework. I'm not sure what you've observed or where, but I can tell you it's certainly not standard or best practice in the industry. It might possibly tell you something about your own code style though - are you writing units which can be treated in isolation? (Certainly not if you depend on a SL, which is a global context of services with no clear boundary)
Ideally a codebase should be designed to maximize unit-testability and reduce the need for integration testing to as little as possible - since this is where most of the "unexpected", or "out of my control" problems are most likely to occur. This testing is more a case of "am I handling all the relevant exceptions" than getting green lights to pass in a unit testing framework. It doesn't really help to make unit tests against code which is expected to fail out in the wild due to whatever circumstance - what matters here is that your code is prepared for the worst and knows how to recover.
It's these cases where mock classes are particularly useful - because you can forcefully simluate any behavior from the external service and make sure your code is working correctly for all the potential circumstances. Having to rely on divine intervention to trigger some event that may only happen 1% of the time in the real-world situation is hardly practical. Unfortunately testing in the wild is often like this - everything works fine 99% of the time.
Even for cases where you're arguing for a fixture with real test data in (from a database), then the reasonable thing to do is extract this data beforehand and encode it into the unit testing language (which is fairly trivial to do). Now you have a reliable test which will continue to work as you update the code. Testing against live data is giving a false sense of security to begin with anyway. Imagine the scenario where you have a bunch of data in the database, you run your unit test against it with all green flags - then after deployment, somebody inserts into the database a value which your code doesn't expect. The unit test shouldn't be testing against real world data, but against data representitive of the possible values it should accept (ie, include all the obvious edge cases which should fail too, but are not likely to exist in the real world DB).
There are good arguments against a service locator - one of them is presented here: http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Patte...
Another argument again the service locator pattern is this: If you ask the locator for a service which has dependencies you have to resolve those dependencies yourself. So you need to know about the specific implemntation of this service interface which defeats the purpse. If you work around that, you end up with something that is pretty close to a DI container.
> they're basically there to avoid the use of globals (and hence, tight coupling)
One could say that you merely delegate the management of the globals to the DI framework, just as you do with a ServiceLocator.
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.
That said, I absolutely despise autowiring and annotation-based DI...
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.
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.
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.
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.
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.
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.
Brevity is the soul of wit.
Here's a summary:
Dependency injection's primary benefit is to aid unit testing.
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.
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...
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.
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.
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.
People often get caught up in "the one true way to do things" mentality. This is engineering, they think, so there must be a single, indisputable, scientifically provable, ISO standardizable correct way to write software. Once I know the one true way, I can mechanically apply it and not have to think about it anymore.
Someone who subscribes to that mentality might go about creating a lot of ThingDoers with doTheThing() methods. In the name of never creating dependencies to concrete classes and having 100% test coverage, it is possible to lose perspective of what is important. If you've made your system less understandable and maintainable than a monolithic procedural class, you've missed the point.
Related functionality needs to remain grouped together for understandability. Abstraction seams need to be created in ways and in places where it makes sense, not mindlessly to every single method in a system. This is more of an art than a science.
One thing that I always keep in the back of my mind is FizzBuzzEnterpriseEdition. It's an absurd example of thoughtless one-true-way architecture taken to its extreme, making an extremely simple task incomprehensible but "pure." If I'm ever writing code and FizzBuzzEnterpriseEdition pops into my head, I stop and evaluate what I'm doing.
The fact is that in this field there is no autopilot and constant reflection and adaptation is required. What works in one scenario doesn't always work in another. What works with one codebase doesn't necessarily work in another. What works with one team doesn't necessarily work with another. Even if it worked phenomenally well in one situation, with one codebase, or with one team. This applies not only to design patterns but pretty much all aspects of this business.
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.)
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
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.
- 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.
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/). 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?
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.
However, Rust doesn't have an OOP or Unit Test culture, so dependency injection is limited to true dependencies.
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.
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?"
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.
maybe this was meant to be humorous?
Years ago I wrote a "get me the hell out of spring" tool: https://code.google.com/p/unsprung/
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.
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
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.