During a code review I have started having a bit of a dilemma as to whether use dependency injection or not. I would like to hear your thoughts, because this is kind of an ongoing theme and would help in the future code reviews as well.
Before I start I want to say that from my knowledge DI is mostly used for dependency management and better, much easier unit testing (correct me if I am wrong please).
Now here is the scenario:
This is the class that will be used as a dependency only once and probably for good. Meaning it will stay that way for a while and no other class will be using it.
Reason being is because it is a refactoring of some legacy code and there was not much to be done but to separate it into another class, at least as a first good step, for following the SRP.
Also, another thing is that the hypothetical doSomethingImportant() hits the database.
public Object doSomethingImportant()
Based on that information do you think it is okay to new up the dependency in the other class as opposed to using DI since:
Dependency management argument kind of falls off since it is only going to be used once.
Unit testing also falls off since I would rather do an integration or acceptance test to see how the method is interacting with the database in a real-life application.
private readonly SomeClass _someClass = new SomeClass();
public Object doSomethingImportantUsingDependency()
I was personally inclined towards doing DI because it is considered good practice, but for a second there it felt like I was blindingly following the rules and not thinking it over since there are always exceptions to the rule.
What are your thoughts on this? I would love to hear.
PS: I don't think this is a generic "when should I use DI" question because it is very specific to this particular situation when unit tests are of no use and the class is going to be used only once so there is no need to centralize it for dependency management (even though it is good practice in general).