Why I've become a dependency injection convert

 To start with, I can't say I've ever had a particular aversion to dependency injection. Early on it was mostly floated as a means to ensuring that everyone who wanted to access an API or Service was accessing the same instance. And that is certainly an important function on some level. But, that alone never seemed to justify the extra work to implement it. I mean, more often than not, most services and APIs, at least in my particular niche, are referenced by boilerplate code, other pre-compiled binaries or some other singular consumer.

But, I made the call when I started work on a new internal SDK to see how far following industry standard practices would get me. And that meant adopting dependency injection in Asp .Net Services.

Now, I also combined this with building my SDK more around ease of extension than the previous iterations dependence on code generation. Both automatic and manually triggered. And that also meant ensuring a focus on extensibility. Which, is yet another important place where dependency injection ties in. You see, in the old world order there was only ever a single implementation of whatever it is we were injecting. But, here I've used it to inject the correct implementation for the current application or even the correct collection of implementations.

When you're writing an SDK, even one for internal use, you're going to hit issues. And lots of them. And, I actually haven't hit all that many relative to what I expected. So, that is a strong indicator of how things are going. But, what is perhaps most important is that thanks to dependency injection, when a problem does arise, 90% of the time I can either point the developer to where in their own code they need to go. Or, I can provide them with alternate implementation containing a fix to test to extend for their purposes. It is actually exceedingly rare that an update to the SDK is required to fix any problem.

And, honestly, if we're being technical... the 10% of cases where  it does "require" an updated SDK, it has almost always been not because an alternate implementation couldn't be injected, but rather because the class in question was heavily coupled with other classes and it was too cumbersome to provide the plurality of implementations which needed to be changed out.

True instances where I actually NEED to make changes on my end to address a problem are rare.

Of course, as the provider of the SDK, I want to address the problems within the SDK where possible. But history has taught me that a single person or team can rarely react quick enough and product teams are often left waiting, potentially hurting customers, when a fix relies explicitly on the SDK team. 

And since our SDK is largely for internal use only, when a blocking problem is encountered I can always share the internal implementations if someone needs to leapfrog me. And then I can either incorporate their changes later, or if they aren't compatible with the direction of the base SDK I can either add in extension points to support their changes or just leave them on their own implementation as a last resort.