# Inversion of Control (IoC) **Inversion of Control (IoC)** is a design principle where the *flow of control* of a program is inverted compared to the traditional procedural model. Instead of your code calling into a library when it needs something, a framework or container calls *your code* at the right moments. The custom code becomes the leaf, not the trunk. It's also known as the **Hollywood Principle**: "Don't call us, we'll call you." Coined as a term by [[Martin Fowler]] in 2004, but the underlying idea predates the name; event loops, GUI frameworks, and the Template Method pattern are all IoC. IoC is a *family* of techniques, not a single one. Common implementations include callbacks and event handlers, the Template Method pattern, Strategy/Observer patterns, plugin architectures, [[Dependency Injection (DI)]], and Service Locator. All of them move the decision of *when* and *with what* to invoke a piece of code from the code itself to an external coordinator. ## Why it matters - **Decoupling**: components depend on contracts, not concrete collaborators. See [[Loose Coupling]]. - **Testability**: behavior can be exercised in isolation; the framework's role can be replaced with a test harness. - **Extensibility**: the framework defines the extension points; new behavior plugs in without modifying the framework. - **Reuse**: the framework is the reusable piece; your code is the variation. ## IoC vs DIP vs DI These three are constantly conflated. They're not the same. | Concept | Type | What it says | |---------|------|--------------| | Inversion of Control | **General principle** | The framework calls your code, not vice versa. | | [[Dependency Inversion Principle (DIP)]] | **Specific design principle** (the "D" in [[SOLID Principles]]) | High-level modules depend on abstractions, not concretions. | | [[Dependency Injection (DI)]] | **Specific technique / pattern** | Dependencies are supplied from outside rather than constructed internally. | DI is one way to implement IoC *and* one way to satisfy DIP. IoC and DIP are about *direction*; DI is about *delivery mechanism*. A program can follow DIP without using DI (e.g., via Service Locator), and can use IoC without DI (e.g., via callbacks or Template Method). ## Where you see it - GUI frameworks (Swing, AWT, Qt, web frameworks): you register handlers, the event loop calls them. - Web frameworks ([[Angular]], React, Spring, NestJS, Rails): the framework owns the request/render lifecycle and dispatches into your controllers/components. - Test runners (JUnit, Jest, Vitest): they discover your tests and invoke them. - Plugin systems: the host loads and calls plugins through a defined contract. ## References - Martin Fowler — *Inversion of Control Containers and the Dependency Injection pattern* (2004) — https://martinfowler.com/articles/injection.html - Martin Fowler — *Inversion of Control* (Bliki) — https://martinfowler.com/bliki/InversionOfControl.html ## Related - [[Dependency Inversion Principle (DIP)]] - [[Dependency Injection (DI)]] - [[SOLID Principles]] - [[Loose Coupling]] - [[High Cohesion]] - [[Composition over Inheritance]]