在C#中使用依赖注入时，为什么调用接口方法会自动调用实现类的方法？

Question

To clarify my question, suppose I have the following very basic statistics interface and class:

public interface IStatistics
{
   void IncrementPacketsDiscovered();
}

public class Statistics : IStatistics
{
   private int numberOfPacketsDiscovered = 0;

   public void IncrementPacketsDiscovered()
   {
      numberOfPacketsDiscovered++;
   }
}

Then suppose I have the following class that receives the injected IStatistics object:

public class Reporter
{
   private IStatistics _statistics;
       
   public Reporter(IStatistics statistics)
   {
      _statistics = statistics;
      _statistics.IncrementPacketsDiscovered();
   }
}

Why is it that I am able to call the IStatistics method IncrementPacketsDiscovered() on the IStatistics object and it automatically knows to fetch the method definition that was implemented in the Statistics class?

Any help would be greatly appreciated. Thank you!

Answer 1

TLDR; because the injected object that implements IStatistics is an instance of the Statistics class, and it is this way because somewhere else you told the dependency resolver to use Statistics whenever you mention IStatistics ..

---

Note that Statistics.IncrementPacketsDiscovered being called is nothing to do with DI per se, you could write this:

IStatistics x = new Statistics();
x.IncrementPacketsDiscovered();

On the outside, x looks like an IStatistics . On the inside, it is a Statistics . If Statistics did something else (other than just implement the interface) it would be easier to see. It would also probably be more clear what's going on if you had something else that implemented IStatistics , like some sort of FakeStatistics that you use in a test scenario - testing is one such valid reason where you'd switch your program back and forth between different suites of objects.

You could just conceive that somewhere outside of all your code is the dependency resolver, a thing created by Microsoft*. It did that first line of code above for you, and later when you said you wanted to have a Reporter it looked and saw "the constructor takes a parameter of anything that implements IStatistic s, and I just happen to have an instance of Statistics here that fits that requirement, so I'll pass that into the Reporter constructor.." because that is what it is configured to do/that is its job.

If you had a FakeStatistics that you used for testing, and a context where you reconfigured the injector to create and supply fake objects then it suddenly starts to make sense why it's a useful way to engineer - you don't have to have 100 places where you said new Statistics where you go through and change them all to say new FakeStatistics . It's also useful to be writing a class and suddenly realize "this class needs statistics.." you add a single argument IStatistics x to the constructor, hit Ctrl . and pick the option to add a property for it and that class now has access to a suitable implementation of IStatistics , supplied by the resolver. You don't have to chase up through everywhere you said new MyXClass(param1, param2) and change it to say new MyXClass(param1, param2, someStatistics) because the job of new ing all your objects is the responsibility of the resolver

By using interfaces and coding up such that "any object that implements this interface can sensibly be used as an input argument to this class" you then open it up to the possibility that a "class instance lookup and provider service" can wire all your app together just by "rummaging around in its currently configured bag of objects for one that will do the job" (and then you change what's in the bag depending on the context)

So where did you put things in the bag? In the part of the program where you configured the resolver, methods like AddScoped , AddTransient , AddSingleton have the dual purpose of mapping a type of class to a type of interface and also configure what sort of lifetime the instance has- resolvers manage instances for you and create/destroy them over the lifetime you specify by which Add* method you use

_{* With this statement I am, of course, making a gross assumption as to which injector you're using. There are other DI/IoC frameworks available for C#, created by others. The overarching concept remains the same; the more you can get the computer to write your code for you, the quicker, easier and more reliable it can be. Establishing dependenceies between objects in your program is one such place where it can make sense to hand it off to software rather than writing it yourself}