I have a discussion with someone at my work. The classes and interfaces look like the following:
public interface ISomeInterface { }
public class ImplementationOfInterface : ISomeInterface { }
public class ClassThatUsesInterface {
private ISomeInterface _interface;
public ISomeInterface Interface {
get => _interface ?? new ImplementationOfInterface();
set => _interface = value;
}
}
99% of the time we would use ImplementationOfInterface
. The last 1% would probably be unit testing purposes.
I have tried reading up on Dependency Injection, Dependency Inversion Principle, Service, SOLID and a bit more unrelated things like Service Locator pattern/anti-pattern, two step initialization anti-pattern and so on, and this way of doing it.
It's half-way clear that the D in SOLID is violated; "Dependency inversion principle; one should "depend upon abstractions, [not] concretions.". Since it's fairly easy to override this in unit tests or switch the implementation if you'd like to... which makes me even more confused about it..
Even tho it's against the D in SOLID and does not really do anything following proper dependency injection, it's really hard to argue against this usage.
Can you come up with articles or powerful arguments for and against the use of this particular "hack" of Property Injection ?
Aucun commentaire:
Enregistrer un commentaire