- 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

- 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.