Here are brief definitions of selected terms, patterns, and other concepts discussed in this book. Each definition includes a reference to the chapter or section where the term is discussed in greater detail.

• Abstraction—A unifying term that encompasses both interfaces and (abstract) base classes. See chapter 1.
• Ambient Context—A DI anti-pattern that supplies application code outside the Composition Root with global access to a Volatile Dependency or its behavior by the use of static class members. See section 5.3.
• Aspect-Oriented Programming (AOP)—An approach to software that aims to reduce boilerplate code required for implementing Cross-Cutting Concerns and other coding patterns. It does this by implementing such patterns in a single place and applying them to a code base either declaratively or based on convention, without modifying the code itself. See chapter 10.
• Auto-Registration—The ability to automatically register components based on a certain convention in a DI Container by scanning one or more assemblies for implementations of desired Abstractions. See section 12.2.3.
• Auto-Wiring—The ability to automatically compose an object graph from maps between Abstractions and concrete types by making use of type information supplied by the compiler and the Common Language Runtime. See section 12.1.2.
• Captive Dependency—A Dependency that’s inadvertently kept alive for too long, because its consumer was given a lifetime that exceeds the Dependency’s expected lifetime. See section 8.4.1.
• Command-Query Separation—The idea that each method should either return a result, but not change the observable state of the system, or change the state, but not produce any value. See section 10.3.3.
• Composer—A unifying term that encompasses any object or method that composes Dependencies. See chapter 8.
• Composition Root—A central place in an application where the entire application is composed from its constituent modules. See section 4.1.
• Configuration as Code—Allows a DI Container’s configuration to be stored as source code. Each mapping between an Abstraction and a particular implementation is expressed explicitly and directly in code. See section 12.2.2.
• Constrained Construction—A DI anti-pattern that forces all implementations of a certain Abstraction to require their constructors to have an identical signature. See section 5.4.
• Constructor Injection—A DI pattern where Dependencies are statically defined as a list of parameters to the class’s constructor. See section 4.2.
• Control Freak—A DI anti-pattern where you depend on a Volatile Dependency in any place other than a Composition Root. It’s the opposite of Inversion of Control. See section 5.1.
• Cross-Cutting Concern—An aspect of a program that affects a larger part of the application. It’s often a non-functional requirement. Typical examples include logging, auditing, access control, and validation. See chapter 9.
• Dependency—In principle, any reference that a module holds to another module. When a module references another module, it depends on it. Informally, the term Dependency is often used instead of the more formal Volatile Dependency. See chapter 1.
• Dependency Inversion Principle—This principle states that higher-level modules in your applications shouldn’t depend on lower-level modules; instead, both types should depend on Abstractions. The D in SOLID. See section 3.1.2. See also SOLID.
• Dependency Lifetime—See Object Lifetime.
• DI Container—A software library that provides DI functionality and automates many of the tasks involved in Object Composition, Interception, and Lifetime Management. It’s an engine that resolves and manages object graphs. See chapter 12.
• Entity—A domain object with an inherent, long-term identity. See section 3.1.2.
• Foreign Default—A default implementation of a Volatile Dependency that’s defined in a different module than the consumer. See section 5.1.3.
• Interception—The ability to intercept calls between two collaborating components in such a way that you can enrich or change the behavior of the Dependency without the need to change the two collaborators themselves. See chapter 9.
• Interface Segregation Principle—This principles states that no client should be forced to depend on methods it doesn’t use. The I in SOLID. See section 6.2.1. See also SOLID.
• Inversion of Control—This concept lets a framework control the lifetime of objects instead of directly controlling them. See chapter 1.
• Leaky Abstraction—Even though an Abstraction is defined, the implementation details show through and thus lock the Abstraction to the implementation. See section 6.2.1.
• Lifestyle—A formalized way of describing the intended lifetime of a Dependency. See chapter 8.
• Lifetime Management—See Object Lifetime.
• Liskov Substitution Principle—A software design principle that states that a consumer should be able to use any implementation of an Abstraction without changing the correctness of the system. The L in SOLID. See section 10.2.3. See also SOLID.
• Local Default—A default implementation of an Abstraction that’s defined in the same assembly as the consumer. See section 4.2.2.
• Method Injection—A DI pattern where Dependencies are injected into the consumer as method parameters. See section 4.3.
• Object Composition—The concept of composing applications from disparate modules. See chapter 7.
• Object Lifetime—Generally speaking, this term covers how any object is created and deallocated. In DI context, this term covers the lifetime of Dependencies. See chapter 8.
• Open/Closed Principle—This principle states that classes should be open for extensibility, but closed for modification. The O in SOLID. See section 4.4.2. See also SOLID.
• Property Injection—A DI pattern where Dependencies are injected into the consumer via writable properties. See section 4.4.
• Pure DI—The practice of applying DI without a DI Container. See part 3.
• Scoped Lifestyle—A Lifestyle where there’s a single instance within a well-defined scope or request, and instances aren’t shared across scopes. See section 8.3.3.
• Seam—A place in application code where Abstractions are used to separate modules. See chapter 1.
• Service Locator—A DI anti-pattern that supplies application components outside the Composition Root with access to an unbounded set of Volatile Dependencies. See section 5.2.
• Setter Injection—See Property Injection.
• Single Responsibility Principle—This principle states that a class should have only a single responsibility. The S in SOLID. See section 2.1.3. See also SOLID.
• Singleton Lifestyle—A Lifestyle where a single instance is reused for all consumers within the scope of a single Composer. See section 8.3.1.
• SOLID—An acronym that stands for five fundamental design principles: Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. See chapter 10.
• Stable Dependency—A Dependency that can be referenced without any detrimental effects. The opposite of a Volatile Dependency. See section 1.3.1.
• Temporal Coupling—Code smell that occurs when there’s an implicit relationship between two or more members of a class, requiring clients to invoke one member before the other. See section 4.3.2.
• Testability—The degree to which an application is susceptible to automated unit tests. See chapter 1.
• Transient Lifestyle—A Lifestyle where all consumers get their own instance of a Dependency. See section 8.3.2.
• Volatile Dependency—A Dependency that involves side effects that can be undesirable at times. This may include modules that don’t yet exist or that have adverse requirements on its runtime environment. These are the Dependencies that are addressed by DI. See section 1.3.2.