Glossary

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

Abstraction

A unifying term that encompasses both interfaces and (abstract) base classes. See chapter 2.

Ambient Context

A DI pattern that makes a strongly typed DEPENDENCY implicitly available via a context which is always present. See chapter 4.

Aspect-Oriented Programming (AOP)

An approach to software that addresses Separation of Concerns by composing CROSS-CUTTING CONCERNS in a declarative manner. See chapter 9.

Auto-wiring

The ability to automatically compose an object graph once mappings from ABSTRACTIONS to concrete types are known. See chapter 3.

Auto-registration

Use of conventions to configure a DI CONTAINER instead of using explicit registrations of each component. See chapter 3.

Bastard Injection

A DI anti-pattern. See chapter 5.

Code as Configuration

Use of imperative code to configure a module or application instead of using an external configuration mechanism, such as a configuration file. See chapter 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 chapter 3.

Constrained Construction

A DI anti-pattern. See chapter 5.

Constructor Injection

A DI pattern where DEPENDENCIES are injected into the consumer as constructor arguments. See chapter 4.

Control Freak

The opposite of INVERSION OF CONTROL. A DI anti-pattern. See chapter 5.

Convention-based Configuration

Another term for AUTO-REGISTRATION.

Cross-Cutting Concern

A concern that spans multiple modules or entire applications. 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.

DI Container

A library or framework that provides reusable DI functionality. See chapter 3.

DTO

Data Transfer Object. See chapter 7.

Entity

A Domain Object with an inherent, long-term identity. See chapter 7.

Foreign Default

A default implementation of an ABSTRACTION that’s defined in a different assembly than the consumer. See chapter 5.

Humble Object

An object that contains little-to-no behavior itself and that instead delegates all its operations to other objects. See chapter 2.

Interception

The act of modifying a DEPEDENCY before it’s passed to its consumer. See chapter 9.

Inversion of Control

Letting a framework control the lifetime of objects instead of directly controlling them. See chapter 2.

Leaky Abstraction

Even though an ABSTRACTION is defined, the implementation details show through and thus lock the ABSTRACTION to the implementation. See chapter 6.

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 chapter 8. See also SOLID.

Local Default

A default implementation of an ABSTRACTION that’s defined in the same assembly as the consumer. See chapter 4.

Method Injection

A DI pattern where DEPENDENCIES are injected into the consumer as method parameters. See chapter 4.

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 also SOLID.

Per Graph Lifestyle

A DEPENDENCY lifecycle scope where we reuse a single instance across several different consumers inside the same object graph, but use separate instances in different object graphs. See chapter 8.

Pooled Lifestyle

A DEPENDENCY lifecycle scope where we reuse a pool of prepared instances. See chapter 8.

Poor Man’s DI

DI without the use of a DI CONTAINER. See part 3.

Property Injection

A DI pattern where DEPENDENCIES are injected into the consumer via writable properties. See chapter 4.

Register Resolve Release

A pattern that describes how a DI CONTAINER should be used. See chapter 3.

Seam

A place in application code where ABSTRACTIONS are used to separate modules. See chapter 1.

Service Locator

A DI anti-pattern. See chapter 5.

Single Responsibility Principle

This principle states that a class should only have a single responsibility. The S in SOLID. See also SOLID.

Singleton Lifestyle

A DEPENDENCY lifecycle scope where a single instance is reused for all consumers. See chapter 8.

Solid

An acronym which stands for five fundamental design principles: SINGLE RESPONSIBILITY PRINCIPLE, OPEN/CLOSED PRINCIPLE, LISKOV SUBSTITUTION PRINCIPLE, Interface Segregation Principle, and Dependency Inversion Principle. See chapter 9.

Stable Dependency

A DEPENDENCY that can be referenced without any detrimental effects. The opposite of a VOLATILE DEPENDENCY. See chapter 1.

Testability

The degree to which an application is susceptible to automated unit tests. See chapter 1.

Transient Lifestyle

A DEPENDENCY lifecycle scope where all consumers get their own instance of a DEPENDENCY. See chapter 8.

Volatile Dependency

A DEPENDENCY that involves side effects that may 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 chapter 1.

Web Request Context Lifestyle

A DEPENDENCY lifecycle scope where a single instance is reused within a single web request. See chapter 8.