It is very easy and common to overuse dependency injection, and I wouldn't endorse the practice of "inject anything that needs an instance". However, you'll need to decide which aspects fall into which group.
One distinction I've seen drawn is "injectables" vs "newables", as in this oft-cited article by Miško Hevery (also on the Google Testing Blog), this article by Giorgio Sironi, and this Dagger 2 StackOverflow answer.
You may want to weigh the advantages of dependency injection, which include:
- ability for the environment to substitute out implementations, particularly in testing against unwritten, heavy, or nondeterministic implementations
- insulation from your dependencies' dependencies, which may change and evolve independently
...against the costs, which include:
- difficulty in telling which implementation may be supplied
- additional Provider classes and instances, which may be expensive on embedded/mobile platforms
- complex syntax and build steps to handle mixing constructor parameters and factories, such as through AutoFactory
Value and model objects, which are unlikely to have multiple or risky implementations, are often squarely in the newable camp; interconnected and interdependent services are often far into the injectable camp. For lightweight services and utils, you'll need to identify the benefits provided above and draw the line based on the benefits you need.