is it possible to do dependency injection that doesn't result in Inversion of Control?

Question

first, I'm new to the software world. so my apologies if this is a simple or bad question.

I've been reading about DI and IOC and I understood DI is one way of achieving IOC ( there are other ways as well). so it kept me thinking, does DI always result in Inversion of Control? does it depend on how you call the methods or classes that benefit from DI? in other words, the flow of your application will decide whether or not DI will result in IOC, is this right?

Answer 1

I think this quote from Dependency Injection Principles, Practices, and Patterns (DIPP&P) pretty much sums it up:

Dependency Injection or Inversion of Control?

The term Inversion of Control originally meant any sort of programming style where an overall framework or runtime controlled the program flow. According to that definition, most software developed on the .NET Framework uses IoC. When you write an ASP.NET Core MVC application, for instance, you create controller classes with action methods, but it’s ASP.NET Core that will be calling your action methods. This means you aren’t in control — the framework is.

These days, we’re so used to working with frameworks that we don’t consider this to be special, but it’s a different model from being in full control of your code. This can still happen for a .NET application, most notably for command-line executables. As soon as Main is invoked, your code is in full control. It controls program flow, lifetime — everything. No special events are being raised and no overridden members are being invoked.

Before DI had a name, people started to refer to libraries that manage Dependencies as Inversion of Control Containers, and soon, the meaning of IoC gradually drifted towards that particular meaning: Inversion of Control over Dependencies. Always the taxonomist, Martin Fowler introduced the term Dependency Injection to specifically refer to IoC in the context of dependency management. Dependency Injection has since been widely accepted as the most correct terminology. In short, IoC is a much broader term that includes, but isn’t limited to, DI.

[source: Section 1.4.1, page 29. Online version]

This quote is written in the context of .NET, but if you filter out the .NET and ASP.NET, it is applicable broadly. In Martin Fowler's original definition, IoC was about frameworks, while DI in itself can be applied without any frameworks, for instance using 'simple' (UI-less) Console applications. This means that, from Fowler's original definition, it is possible to practice DI without applying IoC.

Over the years the term IoC, however, has "drifted" and we now generally see DI as as specialized form of IoC. A "sub type" or "implementation" so to speak, where IoC is the concept or "abstraction." This means that you can't apply DI without IoC, because practicing DI means practicing IoC. You can, however, practice IoC, without practicing DI as there are other IoC implementations, such as Service Locator.