In this chapter, we have examined DI with method injection, perhaps the most ubiquitous of all forms of DI.

When it comes to extracting dependencies from existing code, for the purposes of testing, it might be the method that first comes to mind. Please be careful with this, we do not want to introduce test-induced damage.

Adding parameters to an exported API function for the sole purpose of testing undoubtedly damages UX code. Thankfully, there are some tricks available to us to avoid damaging our API. We can define member functions that only exist in test code. We can also use Just-In-Time (JIT) dependency injection, which we will examine in Chapter 9, Just-in-Time Dependency Injection.

In this chapter, we have looked at the fantastic and powerful context package. You might be surprised to learn that there is even more value we can extract from this package. I encourage you to check out the Go blog (https://blog.golang.org/context) and investigate this package for yourself.

In the next chapter, we are going to apply a specific form of both constructor injection and method injection called DI by config. With it, we will finally untangle the config package from being depended on by just about every other package in our service, making our packages far more decoupled and increasing their reusability potential considerably.