System Design (LLD)Dependency Injection Deep Dive

Dependency Injection Revisited

LevelIntermediate

Duration60 mins

TopicDependency Injection Deep Dive

2 / 4

DI as a Technique vs DI as a Principle

The Dual Nature of Dependency Injection

Dependency Injection is discussed in two distinct but related contexts. Sometimes it refers to a concrete technique—passing dependencies through constructors or setters. Other times it refers to a design philosophy—a principled approach to managing dependencies and structuring software.

This dual nature creates confusion. Developers may implement the technique without understanding the principle, leading to mechanical DI that misses deeper benefits. Conversely, understanding the principle without mastering the technique leaves engineers unable to apply DI effectively.

This page clarifies both perspectives, showing how they complement each other and when each viewpoint applies.

What You Will Learn

By the end of this page, you will understand DI as both a mechanical technique and a guiding principle. You'll know when to apply each perspective and how they combine to create genuinely flexible, maintainable software architectures.

DI as a Technique: The Mechanical View

At its most concrete, Dependency Injection is a technique for supplying dependencies to objects. The technique has specific mechanical characteristics:

Definition (Technique View):

Dependency Injection is a technique whereby one object (the injector) supplies the dependencies of another object (the dependent). The dependent does not create or locate its dependencies; it receives them from an external source.

This definition focuses on the how: the mechanics of passing dependencies. It's implementation-focused and directly applicable to code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
// ═══════════════════════════════════════════
// TECHNIQUE 1: Constructor Injection
// Dependencies passed through constructor
// ═══════════════════════════════════════════
class OrderProcessor {
    private readonly paymentService: IPaymentService;
    private readonly inventoryService: IInventoryService;
    
    // Dependencies declared as constructor parameters
    constructor(
        paymentService: IPaymentService,
        inventoryService: IInventoryService
    ) {
        this.paymentService = paymentService;
        this.inventoryService = inventoryService;
    }
    
    process(order: Order): ProcessResult {
        // Use injected dependencies
        const paymentResult = this.paymentService.charge(order.payment);
        const inventoryResult = this.inventoryService.reserve(order.items);
        return { payment: paymentResult, inventory: inventoryResult };
    }
}
 
// Usage: Inject at construction time
const processor = new OrderProcessor(
    new StripePaymentService(),
    new WarehouseInventoryService()
);
 
// ═══════════════════════════════════════════
// TECHNIQUE 2: Setter Injection
// Dependencies passed through setter methods
// ═══════════════════════════════════════════
class NotificationService {
    private emailProvider?: IEmailProvider;
    private smsProvider?: ISmsProvider;
    
    // Dependencies set after construction
    setEmailProvider(provider: IEmailProvider): void {
        this.emailProvider = provider;
    }
    
    setSmsProvider(provider: ISmsProvider): void {
        this.smsProvider = provider;
    }
    
    notify(message: Message): void {
        this.emailProvider?.send(message);
        this.smsProvider?.send(message);
    }
}
 
// Usage: Inject via setters
const notifier = new NotificationService();
notifier.setEmailProvider(new SendGridProvider());
notifier.setSmsProvider(new TwilioProvider());
 
// ═══════════════════════════════════════════
// TECHNIQUE 3: Interface Injection
// Dependency implementing an injection interface
// ═══════════════════════════════════════════
interface ILoggerInjectable {
    setLogger(logger: ILogger): void;
}
 
class MetricsCollector implements ILoggerInjectable {
    private logger!: ILogger;
    
    // Injection via interface method
    setLogger(logger: ILogger): void {
        this.logger = logger;
    }
    
    recordMetric(name: string, value: number): void {
        this.logger.log(`Metric recorded: ${name} = ${value}`);
        // ... metric recording logic
    }
}
 
// Usage: Inject via interface
const collector = new MetricsCollector();
(collector as ILoggerInjectable).setLogger(new ConsoleLogger());

Characteristics of the Technique View:

When we treat DI as a technique, we focus on:

Specific injection patterns — Constructor, setter, or interface injection
Object creation mechanics — How and where objects are instantiated
Parameter passing — How dependencies flow from creator to consumer
Container integration — How DI frameworks automate injection

This view is practical and implementation-oriented. It answers: 'How do I inject this dependency?' and 'What injection style should I use here?'

When the Technique View Applies

•Deciding between constructor and setter injection for a specific dependency
•Configuring an IoC container with registration and resolution rules
•Refactoring a class to accept dependencies instead of creating them
•Writing tests that substitute mock objects for real dependencies
•Debugging dependency resolution failures in a container

DI as a Principle: The Philosophical View

Beyond the mechanics, Dependency Injection represents a broader philosophy about how software should be structured. This philosophical view encompasses design intent, architectural decisions, and principles that transcend any specific implementation technique.

Definition (Principle View):

Dependency Injection is a design approach that promotes loose coupling by ensuring that objects depend on abstractions rather than concrete implementations, and that the responsibility for managing dependencies is externalized from the objects that use them.

This definition focuses on the why and the what: the goals we're trying to achieve and the constraints we impose on our designs.

Core Tenets of DI as a Principle

•Abstraction Orientation — Design to interfaces, not implementations. Every significant dependency should have an abstraction layer that defines the contract without exposing implementation details.
•External Dependency Management — Objects should not create or locate their own dependencies. This responsibility belongs elsewhere—in composition roots, factories, or containers.
•Explicit Declaration — Dependencies should be visible and declared, not hidden in implementation details. Looking at a class should reveal what it needs to function.
•Substitutability — Dependencies should be substitutable. Any implementation of the required interface should work without the consumer knowing the difference.
•Separation of Construction from Use — The code that uses objects should not be the same code that creates objects. These are separate concerns with different responsibilities.

Principle Drives Technique:

The principle informs which techniques to apply and when. A developer who understands only the technique might mechanically inject every collaborator. A developer who understands the principle knows why DI matters and can make thoughtful decisions about where it applies.

Consider this contrast:

Technique Without Principle

•Injects everything, including stable utilities
•Creates interfaces for every class, even when only one implementation exists
•Uses DI container for all object creation
•Complex container configuration with minimal benefit
•DI becomes bureaucracy, not benefit

Principle Guiding Technique

•Injects only volatile dependencies
•Creates interfaces where substitution is meaningful
•Uses container where it adds value
•Simple configuration, high impact
•DI enables flexibility and testing

Volatile vs. Stable Dependencies

A key insight from the principled view: inject volatile dependencies (things that change, need testing flexibility, or vary across environments) but directly reference stable dependencies (standard library utilities, well-tested framework components, pure functions). Not everything needs injection.

Relationship to SOLID and Other Principles

DI as a principle doesn't exist in isolation. It's part of a constellation of design principles that together guide well-structured software. Understanding these relationships deepens appreciation for when and why DI matters.

DI's Relationship to Design Principles
Principle	Relationship to DI	How DI Supports It
Single Responsibility (SRP)	Separation of concerns	DI separates 'using dependencies' from 'creating dependencies'—each class has one responsibility, not object assembly
Open-Closed (OCP)	Extension without modification	DI enables new behaviors by injecting different implementations—the consumer code never changes
Liskov Substitution (LSP)	Substitutability guarantee	DI depends on LSP—injected implementations must be substitutable for their abstractions
Interface Segregation (ISP)	Focused interfaces	DI works best with focused interfaces—injecting a minimal dependency surface
Dependency Inversion (DIP)	Foundation for DI	DI is the primary technique for achieving DIP—abstractions enable injection

DI and Inversion of Control:

Dependency Injection is often discussed alongside Inversion of Control (IoC). The relationship is hierarchical:

Inversion of Control (broad principle)
│
├── Dependency Injection (one form of IoC)
│   ├── Constructor Injection
│   ├── Setter Injection
│   └── Interface Injection
│
├── Template Method Pattern (another form of IoC)
│
├── Event-driven Programming (another form of IoC)
│
└── Plugin Architectures (another form of IoC)

IoC means inverting the traditional control flow—instead of your code calling framework code, framework code calls your code. DI is IoC applied specifically to dependencies: instead of objects controlling their dependencies, an external entity controls dependency provision.

All DI is IoC, but not all IoC is DI. A Template Method inverts control (subclass provides steps) but isn't about dependencies. Understanding this hierarchy clarifies that DI is one powerful application of a broader principle.

SOLID Synergy

DI is most powerful when combined with the other SOLID principles. SRP keeps classes focused. OCP enables extension. LSP ensures substitutability. ISP creates minimal interfaces. DIP provides the abstraction foundation. Together, they create systems where DI delivers maximum value.

The Danger: Technique Without Principle

Understanding DI only as a technique leads to problematic patterns. Developers mechanically apply injection without understanding why, resulting in code that's structurally DI-compliant but fails to achieve DI's goals.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// ═══════════════════════════════════════════
// ANTI-PATTERN 1: Injecting Stable Dependencies
// ═══════════════════════════════════════════
class ReportGenerator {
    constructor(
        private readonly logger: ILogger,        // Reasonable - might switch implementations
        private readonly formatter: IFormatter,  // Reasonable - multiple formatters possible
        private readonly dateLib: IDateLibrary,  // WHY? - Date libraries rarely change
        private readonly mathLib: IMathLibrary,  // WHY? - Math doesn't have 'implementations'
        private readonly stringLib: IStringLib   // WHY? - String utilities are stable
    ) {}
}
 
// The abstraction for Math() accomplishes nothing:
interface IMathLibrary {
    add(a: number, b: number): number;
    multiply(a: number, b: number): number;
}
 
// This 'implementation' just wraps built-in operations:
class StandardMathLibrary implements IMathLibrary {
    add(a: number, b: number) { return a + b; }
    multiply(a: number, b: number) { return a * b; }
}
 
// ═══════════════════════════════════════════
// ANTI-PATTERN 2: Interface for Every Class
// ═══════════════════════════════════════════
// Even when only ONE implementation will ever exist:
interface IUserNameFormatter {
    format(user: User): string;
}
 
// Only implementation, will never be substituted:
class UserNameFormatter implements IUserNameFormatter {
    format(user: User): string {
        return `${user.firstName} ${user.lastName}`;
    }
}
 
// Now we must maintain two files that say the same thing.
// Changes require updating both the interface and implementation.
// The interface provides no value—it's pure ceremony.
 
// ═══════════════════════════════════════════
// ANTI-PATTERN 3: Container for Simple Applications
// ═══════════════════════════════════════════
// A 3-class CLI tool doesn't need:
container.register<IConfigLoader>('ConfigLoader', ConfigLoader);
container.register<IFileProcessor>('FileProcessor', FileProcessor);
container.register<IOutputWriter>('OutputWriter', OutputWriter);
container.register<IApplication>('Application', Application);
 
// When this would suffice:
const app = new Application(
    new ConfigLoader(),
    new FileProcessor(),
    new OutputWriter()
);

Signs of Technique Without Principle

•Every class has an interface — Including classes that will never have alternative implementations. Interfaces become empty ceremony.
•Primitives are injected — String utilities, math operations, and standard library functions wrapped in interfaces for no reason.
•Container everywhere — DI container used even in simple applications where manual wiring would be clearer and simpler.
•No testability improvement — Despite DI structure, tests still require complex setup because the wrong things were abstracted.
•Configuration complexity — Container configuration becomes a maintenance burden, with registration code longer than business logic.

The Bureaucracy Problem

When DI becomes bureaucracy, developers start resenting it. They see interfaces as obstacles, injection as ceremony, and containers as complexity for complexity's sake. This happens when technique is applied without principled understanding of why and when DI helps.

The Other Side: Principle Without Technique

Understanding the principle without mastering the technique creates different problems. Developers may appreciate why DI matters but fail to implement it correctly, leading to half-measures that don't deliver promised benefits.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// ═══════════════════════════════════════════
// ANTI-PATTERN 1: Interfaces but Still Tight Coupling
// ═══════════════════════════════════════════
interface IPaymentGateway {
    processPayment(amount: Money): PaymentResult;
}
 
class OrderService {
    private gateway: IPaymentGateway;
    
    constructor() {
        // Understands interfaces matter, but still creates internally
        this.gateway = new StripeGateway();  // Defeat the purpose!
    }
}
 
// Interface exists but provides zero substitutability
// Testing still requires Stripe connection
// Environment switching still requires code changes
 
// ═══════════════════════════════════════════
// ANTI-PATTERN 2: Factory that Hides the Problem
// ═══════════════════════════════════════════
class PaymentServiceFactory {
    createGateway(): IPaymentGateway {
        // Hardcoded decision still exists, just relocated
        return new StripeGateway();
    }
}
 
class OrderService {
    private gateway: IPaymentGateway;
    
    constructor() {
        // Factory used but problem just moved
        this.gateway = new PaymentServiceFactory().createGateway();
    }
}
 
// ═══════════════════════════════════════════
// ANTI-PATTERN 3: Late Binding Without Injection
// ═══════════════════════════════════════════
class OrderService {
    private gateway?: IPaymentGateway;
    
    // No constructor injection
    constructor() {}
    
    // Client must remember to call this
    setGateway(gateway: IPaymentGateway): void {
        this.gateway = gateway;
    }
    
    processOrder(order: Order): void {
        // Potential null/undefined if setter not called
        if (!this.gateway) {
            throw new Error('Gateway not configured!');
        }
        this.gateway.processPayment(order.total);
    }
}
 
// Easy to use incorrectly:
const service = new OrderService();
service.processOrder(order);  // CRASH - forgot to set gateway

Signs of Principle Without Technique

•Interfaces exist but instantiation is internal — Classes have interface-typed fields but create concrete implementations in constructors.
•Factories that just relocate the problem — Factory classes that hardcode implementations instead of receiving them.
•Nullable dependencies with late binding — Dependencies set via optional methods, enabling invalid states.
•Service locators instead of injection — Classes fetching dependencies from global registries instead of receiving them.
•Configuration not externalized — Code changes required to switch implementations despite interface abstractions.

Good Intent, Poor Execution

These patterns show developers who understand that coupling is bad and interfaces are good. But without proper DI technique, they've created the appearance of flexibility without the reality. Tests still need real implementations, environments still need code changes.

Unifying Technique and Principle

The goal is integration: principled understanding guiding technical implementation. When technique and principle unite, DI delivers its full value—flexible, testable, maintainable systems without unnecessary complexity.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
// ═══════════════════════════════════════════
// PRINCIPLE: Volatile Dependency → Inject
// TECHNIQUE: Constructor Injection (mandatory)
// ═══════════════════════════════════════════
interface IPaymentGateway {
    processPayment(amount: Money): PaymentResult;
}
 
interface IInventoryService {
    reserve(items: OrderItem[]): ReservationResult;
}
 
interface INotificationService {
    notify(customer: Customer, message: string): void;
}
 
class OrderProcessor {
    // All dependencies declared, all injected via constructor
    constructor(
        private readonly paymentGateway: IPaymentGateway,
        private readonly inventoryService: IInventoryService,
        private readonly notificationService: INotificationService
    ) {}
    
    async process(order: Order): Promise<ProcessingResult> {
        // OrderProcessor focuses on orchestration
        // It doesn't know or care about implementations
        
        const reservation = await this.inventoryService.reserve(order.items);
        if (!reservation.success) {
            return ProcessingResult.failed('Inventory unavailable');
        }
        
        const payment = await this.paymentGateway.processPayment(order.total);
        if (!payment.success) {
            await this.inventoryService.release(reservation.id);
            return ProcessingResult.failed('Payment declined');
        }
        
        await this.notificationService.notify(
            order.customer,
            'Your order has been confirmed!'
        );
        
        return ProcessingResult.success(order.id);
    }
}
 
// ═══════════════════════════════════════════
// PRINCIPLE: Stable Dependency → Direct Reference
// TECHNIQUE: No injection needed
// ═══════════════════════════════════════════
class OrderProcessor {
    constructor(/* volatile deps only */) {}
    
    process(order: Order): ProcessingResult {
        // Date utilities: stable, no injection needed
        const timestamp = new Date().toISOString();
        
        // UUID generation: stable, no injection needed
        const orderId = crypto.randomUUID();
        
        // JSON operations: stable, no injection needed
        const serialized = JSON.stringify(order);
        
        // Logger: possibly volatile, judgment call
        // If environments need different loggers, inject
        // If console.log suffices everywhere, don't
    }
}
 
// ═══════════════════════════════════════════
// COMPOSITION: Where Wiring Happens
// ═══════════════════════════════════════════
// In main.ts or composition root:
function createOrderProcessor(): OrderProcessor {
    // Environment-specific construction
    const gateway = process.env.PAYMENT_MODE === 'stripe'
        ? new StripeGateway(process.env.STRIPE_KEY)
        : new SquareGateway(process.env.SQUARE_KEY);
    
    const inventory = new WarehouseInventoryService(
        new DatabaseConnection(process.env.DB_URL)
    );
    
    const notifications = new TwilioNotificationService(
        process.env.TWILIO_SID,
        process.env.TWILIO_TOKEN
    );
    
    return new OrderProcessor(gateway, inventory, notifications);
}
 
// In test files:
function createTestOrderProcessor(): OrderProcessor {
    return new OrderProcessor(
        new MockPaymentGateway(),     // Instant, no network
        new MockInventoryService(),    // Instant, no database
        new MockNotificationService()  // Instant, no SMS API
    );
}

Signs of Unified Understanding

•Selective injection — Only volatile, substitutable dependencies are injected. Stable utilities are used directly.
•Interfaces where meaningful — Abstractions exist when multiple implementations are likely or when testability requires substitution.
•Constructor injection for required deps — Dependencies needed for the object to function are constructor parameters, ensuring valid state.
•Clear composition root — Object graph assembly happens in one place, not scattered throughout business logic.
•Tests are simple — Mocks substitute easily, tests run fast, edge cases are testable in isolation.

A Decision Framework: When to Apply DI

Unifying technique and principle requires a decision framework. Not every collaborator needs injection. The principle helps us decide; the technique helps us implement.

Key Questions for Each Dependency

•Is it volatile? — Does this dependency change often? Is the implementation likely to evolve? Volatile dependencies benefit from injection.
•Does it have side effects? — Does it write to disk, call APIs, send emails? Side-effect dependencies need test substitution.
•Are there multiple implementations? — Different implementations for different contexts? Injection enables switching.
•Does it vary by environment? — Production vs. development vs. testing differences? Injection enables configuration-driven selection.
•Does testing require isolation? — Would real behavior make tests slow, flaky, or complex? Injection enables test doubles.
•Is the benefit worth the complexity? — Does adding interface + injection add value, or just ceremony?

Start Conservative

When uncertain, don't inject. It's easier to add injection later (refactoring to receive a dependency) than to remove it (hunting down all injection points and container configurations). Err on the side of simplicity; add DI when pain points emerge.

Summary: Two Perspectives, One Practice

Dependency Injection operates at two levels—and mastery requires understanding both:

As a Technique:

Specific patterns for passing dependencies (constructor, setter, interface)
Mechanics of object creation and wiring
Container configuration and resolution
Practical implementation decisions

As a Principle:

Design philosophy favoring abstraction and loose coupling
Decision framework for where DI applies
Integration with SOLID and other design principles
Understanding of why injection matters

Neither perspective alone suffices. Technique without principle becomes mechanical ceremony. Principle without technique becomes good intent without delivery.

Key Takeaways

•DI is both technique and principle — Understand both perspectives for effective application.
•Technique answers 'how' — Constructor injection, setter injection, container configuration.
•Principle answers 'why' and 'when' — Loose coupling, testability, volatility assessment.
•Neither alone suffices — Mechanical DI misses the point; philosophical DI without technique doesn't ship.
•Apply selectively — Inject volatile, testable-needs, multi-implementation dependencies. Skip stable utilities.
•Let principle guide technique — Ask why before implementing how.

Page Complete

You now understand Dependency Injection as both a concrete technique and a guiding principle. In the next page, we'll explore the full benefits of DI—flexibility, testability, and maintainability—with deeper technical examples.

2 / 4

Loading learning content...

System Design (LLD)Dependency Injection Deep Dive

Dependency Injection Revisited

LevelIntermediate

Duration60 mins

TopicDependency Injection Deep Dive

2 / 4

DI as a Technique vs DI as a Principle

The Dual Nature of Dependency Injection

This page clarifies both perspectives, showing how they complement each other and when each viewpoint applies.

What You Will Learn

DI as a Technique: The Mechanical View

At its most concrete, Dependency Injection is a technique for supplying dependencies to objects. The technique has specific mechanical characteristics:

Definition (Technique View):

This definition focuses on the how: the mechanics of passing dependencies. It's implementation-focused and directly applicable to code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
// ═══════════════════════════════════════════
// TECHNIQUE 1: Constructor Injection
// Dependencies passed through constructor
// ═══════════════════════════════════════════
class OrderProcessor {
    private readonly paymentService: IPaymentService;
    private readonly inventoryService: IInventoryService;
    
    // Dependencies declared as constructor parameters
    constructor(
        paymentService: IPaymentService,
        inventoryService: IInventoryService
    ) {
        this.paymentService = paymentService;
        this.inventoryService = inventoryService;
    }
    
    process(order: Order): ProcessResult {
        // Use injected dependencies
        const paymentResult = this.paymentService.charge(order.payment);
        const inventoryResult = this.inventoryService.reserve(order.items);
        return { payment: paymentResult, inventory: inventoryResult };
    }
}
 
// Usage: Inject at construction time
const processor = new OrderProcessor(
    new StripePaymentService(),
    new WarehouseInventoryService()
);
 
// ═══════════════════════════════════════════
// TECHNIQUE 2: Setter Injection
// Dependencies passed through setter methods
// ═══════════════════════════════════════════
class NotificationService {
    private emailProvider?: IEmailProvider;
    private smsProvider?: ISmsProvider;
    
    // Dependencies set after construction
    setEmailProvider(provider: IEmailProvider): void {
        this.emailProvider = provider;
    }
    
    setSmsProvider(provider: ISmsProvider): void {
        this.smsProvider = provider;
    }
    
    notify(message: Message): void {
        this.emailProvider?.send(message);
        this.smsProvider?.send(message);
    }
}
 
// Usage: Inject via setters
const notifier = new NotificationService();
notifier.setEmailProvider(new SendGridProvider());
notifier.setSmsProvider(new TwilioProvider());
 
// ═══════════════════════════════════════════
// TECHNIQUE 3: Interface Injection
// Dependency implementing an injection interface
// ═══════════════════════════════════════════
interface ILoggerInjectable {
    setLogger(logger: ILogger): void;
}
 
class MetricsCollector implements ILoggerInjectable {
    private logger!: ILogger;
    
    // Injection via interface method
    setLogger(logger: ILogger): void {
        this.logger = logger;
    }
    
    recordMetric(name: string, value: number): void {
        this.logger.log(`Metric recorded: ${name} = ${value}`);
        // ... metric recording logic
    }
}
 
// Usage: Inject via interface
const collector = new MetricsCollector();
(collector as ILoggerInjectable).setLogger(new ConsoleLogger());

Characteristics of the Technique View:

When we treat DI as a technique, we focus on:

Specific injection patterns — Constructor, setter, or interface injection
Object creation mechanics — How and where objects are instantiated
Parameter passing — How dependencies flow from creator to consumer
Container integration — How DI frameworks automate injection

This view is practical and implementation-oriented. It answers: 'How do I inject this dependency?' and 'What injection style should I use here?'

When the Technique View Applies

•Deciding between constructor and setter injection for a specific dependency
•Configuring an IoC container with registration and resolution rules
•Refactoring a class to accept dependencies instead of creating them
•Writing tests that substitute mock objects for real dependencies
•Debugging dependency resolution failures in a container

DI as a Principle: The Philosophical View

Definition (Principle View):

This definition focuses on the why and the what: the goals we're trying to achieve and the constraints we impose on our designs.

Core Tenets of DI as a Principle

•Abstraction Orientation — Design to interfaces, not implementations. Every significant dependency should have an abstraction layer that defines the contract without exposing implementation details.
•External Dependency Management — Objects should not create or locate their own dependencies. This responsibility belongs elsewhere—in composition roots, factories, or containers.
•Explicit Declaration — Dependencies should be visible and declared, not hidden in implementation details. Looking at a class should reveal what it needs to function.
•Substitutability — Dependencies should be substitutable. Any implementation of the required interface should work without the consumer knowing the difference.
•Separation of Construction from Use — The code that uses objects should not be the same code that creates objects. These are separate concerns with different responsibilities.

Principle Drives Technique:

Consider this contrast:

Technique Without Principle

•Injects everything, including stable utilities
•Creates interfaces for every class, even when only one implementation exists
•Uses DI container for all object creation
•Complex container configuration with minimal benefit
•DI becomes bureaucracy, not benefit

Principle Guiding Technique

•Injects only volatile dependencies
•Creates interfaces where substitution is meaningful
•Uses container where it adds value
•Simple configuration, high impact
•DI enables flexibility and testing

Volatile vs. Stable Dependencies

Relationship to SOLID and Other Principles

DI's Relationship to Design Principles
Principle	Relationship to DI	How DI Supports It
Single Responsibility (SRP)	Separation of concerns	DI separates 'using dependencies' from 'creating dependencies'—each class has one responsibility, not object assembly
Open-Closed (OCP)	Extension without modification	DI enables new behaviors by injecting different implementations—the consumer code never changes
Liskov Substitution (LSP)	Substitutability guarantee	DI depends on LSP—injected implementations must be substitutable for their abstractions
Interface Segregation (ISP)	Focused interfaces	DI works best with focused interfaces—injecting a minimal dependency surface
Dependency Inversion (DIP)	Foundation for DI	DI is the primary technique for achieving DIP—abstractions enable injection

DI and Inversion of Control:

Dependency Injection is often discussed alongside Inversion of Control (IoC). The relationship is hierarchical:

Inversion of Control (broad principle)
│
├── Dependency Injection (one form of IoC)
│   ├── Constructor Injection
│   ├── Setter Injection
│   └── Interface Injection
│
├── Template Method Pattern (another form of IoC)
│
├── Event-driven Programming (another form of IoC)
│
└── Plugin Architectures (another form of IoC)

SOLID Synergy

The Danger: Technique Without Principle

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// ═══════════════════════════════════════════
// ANTI-PATTERN 1: Injecting Stable Dependencies
// ═══════════════════════════════════════════
class ReportGenerator {
    constructor(
        private readonly logger: ILogger,        // Reasonable - might switch implementations
        private readonly formatter: IFormatter,  // Reasonable - multiple formatters possible
        private readonly dateLib: IDateLibrary,  // WHY? - Date libraries rarely change
        private readonly mathLib: IMathLibrary,  // WHY? - Math doesn't have 'implementations'
        private readonly stringLib: IStringLib   // WHY? - String utilities are stable
    ) {}
}
 
// The abstraction for Math() accomplishes nothing:
interface IMathLibrary {
    add(a: number, b: number): number;
    multiply(a: number, b: number): number;
}
 
// This 'implementation' just wraps built-in operations:
class StandardMathLibrary implements IMathLibrary {
    add(a: number, b: number) { return a + b; }
    multiply(a: number, b: number) { return a * b; }
}
 
// ═══════════════════════════════════════════
// ANTI-PATTERN 2: Interface for Every Class
// ═══════════════════════════════════════════
// Even when only ONE implementation will ever exist:
interface IUserNameFormatter {
    format(user: User): string;
}
 
// Only implementation, will never be substituted:
class UserNameFormatter implements IUserNameFormatter {
    format(user: User): string {
        return `${user.firstName} ${user.lastName}`;
    }
}
 
// Now we must maintain two files that say the same thing.
// Changes require updating both the interface and implementation.
// The interface provides no value—it's pure ceremony.
 
// ═══════════════════════════════════════════
// ANTI-PATTERN 3: Container for Simple Applications
// ═══════════════════════════════════════════
// A 3-class CLI tool doesn't need:
container.register<IConfigLoader>('ConfigLoader', ConfigLoader);
container.register<IFileProcessor>('FileProcessor', FileProcessor);
container.register<IOutputWriter>('OutputWriter', OutputWriter);
container.register<IApplication>('Application', Application);
 
// When this would suffice:
const app = new Application(
    new ConfigLoader(),
    new FileProcessor(),
    new OutputWriter()
);

Signs of Technique Without Principle

•Every class has an interface — Including classes that will never have alternative implementations. Interfaces become empty ceremony.
•Primitives are injected — String utilities, math operations, and standard library functions wrapped in interfaces for no reason.
•Container everywhere — DI container used even in simple applications where manual wiring would be clearer and simpler.
•No testability improvement — Despite DI structure, tests still require complex setup because the wrong things were abstracted.
•Configuration complexity — Container configuration becomes a maintenance burden, with registration code longer than business logic.

The Bureaucracy Problem

The Other Side: Principle Without Technique

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// ═══════════════════════════════════════════
// ANTI-PATTERN 1: Interfaces but Still Tight Coupling
// ═══════════════════════════════════════════
interface IPaymentGateway {
    processPayment(amount: Money): PaymentResult;
}
 
class OrderService {
    private gateway: IPaymentGateway;
    
    constructor() {
        // Understands interfaces matter, but still creates internally
        this.gateway = new StripeGateway();  // Defeat the purpose!
    }
}
 
// Interface exists but provides zero substitutability
// Testing still requires Stripe connection
// Environment switching still requires code changes
 
// ═══════════════════════════════════════════
// ANTI-PATTERN 2: Factory that Hides the Problem
// ═══════════════════════════════════════════
class PaymentServiceFactory {
    createGateway(): IPaymentGateway {
        // Hardcoded decision still exists, just relocated
        return new StripeGateway();
    }
}
 
class OrderService {
    private gateway: IPaymentGateway;
    
    constructor() {
        // Factory used but problem just moved
        this.gateway = new PaymentServiceFactory().createGateway();
    }
}
 
// ═══════════════════════════════════════════
// ANTI-PATTERN 3: Late Binding Without Injection
// ═══════════════════════════════════════════
class OrderService {
    private gateway?: IPaymentGateway;
    
    // No constructor injection
    constructor() {}
    
    // Client must remember to call this
    setGateway(gateway: IPaymentGateway): void {
        this.gateway = gateway;
    }
    
    processOrder(order: Order): void {
        // Potential null/undefined if setter not called
        if (!this.gateway) {
            throw new Error('Gateway not configured!');
        }
        this.gateway.processPayment(order.total);
    }
}
 
// Easy to use incorrectly:
const service = new OrderService();
service.processOrder(order);  // CRASH - forgot to set gateway

Signs of Principle Without Technique

•Interfaces exist but instantiation is internal — Classes have interface-typed fields but create concrete implementations in constructors.
•Factories that just relocate the problem — Factory classes that hardcode implementations instead of receiving them.
•Nullable dependencies with late binding — Dependencies set via optional methods, enabling invalid states.
•Service locators instead of injection — Classes fetching dependencies from global registries instead of receiving them.
•Configuration not externalized — Code changes required to switch implementations despite interface abstractions.

Good Intent, Poor Execution

Unifying Technique and Principle

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
// ═══════════════════════════════════════════
// PRINCIPLE: Volatile Dependency → Inject
// TECHNIQUE: Constructor Injection (mandatory)
// ═══════════════════════════════════════════
interface IPaymentGateway {
    processPayment(amount: Money): PaymentResult;
}
 
interface IInventoryService {
    reserve(items: OrderItem[]): ReservationResult;
}
 
interface INotificationService {
    notify(customer: Customer, message: string): void;
}
 
class OrderProcessor {
    // All dependencies declared, all injected via constructor
    constructor(
        private readonly paymentGateway: IPaymentGateway,
        private readonly inventoryService: IInventoryService,
        private readonly notificationService: INotificationService
    ) {}
    
    async process(order: Order): Promise<ProcessingResult> {
        // OrderProcessor focuses on orchestration
        // It doesn't know or care about implementations
        
        const reservation = await this.inventoryService.reserve(order.items);
        if (!reservation.success) {
            return ProcessingResult.failed('Inventory unavailable');
        }
        
        const payment = await this.paymentGateway.processPayment(order.total);
        if (!payment.success) {
            await this.inventoryService.release(reservation.id);
            return ProcessingResult.failed('Payment declined');
        }
        
        await this.notificationService.notify(
            order.customer,
            'Your order has been confirmed!'
        );
        
        return ProcessingResult.success(order.id);
    }
}
 
// ═══════════════════════════════════════════
// PRINCIPLE: Stable Dependency → Direct Reference
// TECHNIQUE: No injection needed
// ═══════════════════════════════════════════
class OrderProcessor {
    constructor(/* volatile deps only */) {}
    
    process(order: Order): ProcessingResult {
        // Date utilities: stable, no injection needed
        const timestamp = new Date().toISOString();
        
        // UUID generation: stable, no injection needed
        const orderId = crypto.randomUUID();
        
        // JSON operations: stable, no injection needed
        const serialized = JSON.stringify(order);
        
        // Logger: possibly volatile, judgment call
        // If environments need different loggers, inject
        // If console.log suffices everywhere, don't
    }
}
 
// ═══════════════════════════════════════════
// COMPOSITION: Where Wiring Happens
// ═══════════════════════════════════════════
// In main.ts or composition root:
function createOrderProcessor(): OrderProcessor {
    // Environment-specific construction
    const gateway = process.env.PAYMENT_MODE === 'stripe'
        ? new StripeGateway(process.env.STRIPE_KEY)
        : new SquareGateway(process.env.SQUARE_KEY);
    
    const inventory = new WarehouseInventoryService(
        new DatabaseConnection(process.env.DB_URL)
    );
    
    const notifications = new TwilioNotificationService(
        process.env.TWILIO_SID,
        process.env.TWILIO_TOKEN
    );
    
    return new OrderProcessor(gateway, inventory, notifications);
}
 
// In test files:
function createTestOrderProcessor(): OrderProcessor {
    return new OrderProcessor(
        new MockPaymentGateway(),     // Instant, no network
        new MockInventoryService(),    // Instant, no database
        new MockNotificationService()  // Instant, no SMS API
    );
}

Signs of Unified Understanding

•Selective injection — Only volatile, substitutable dependencies are injected. Stable utilities are used directly.
•Interfaces where meaningful — Abstractions exist when multiple implementations are likely or when testability requires substitution.
•Constructor injection for required deps — Dependencies needed for the object to function are constructor parameters, ensuring valid state.
•Clear composition root — Object graph assembly happens in one place, not scattered throughout business logic.
•Tests are simple — Mocks substitute easily, tests run fast, edge cases are testable in isolation.

A Decision Framework: When to Apply DI

Unifying technique and principle requires a decision framework. Not every collaborator needs injection. The principle helps us decide; the technique helps us implement.

Key Questions for Each Dependency

•Is it volatile? — Does this dependency change often? Is the implementation likely to evolve? Volatile dependencies benefit from injection.
•Does it have side effects? — Does it write to disk, call APIs, send emails? Side-effect dependencies need test substitution.
•Are there multiple implementations? — Different implementations for different contexts? Injection enables switching.
•Does it vary by environment? — Production vs. development vs. testing differences? Injection enables configuration-driven selection.
•Does testing require isolation? — Would real behavior make tests slow, flaky, or complex? Injection enables test doubles.
•Is the benefit worth the complexity? — Does adding interface + injection add value, or just ceremony?

Start Conservative

Summary: Two Perspectives, One Practice

Dependency Injection operates at two levels—and mastery requires understanding both:

As a Technique:

Specific patterns for passing dependencies (constructor, setter, interface)
Mechanics of object creation and wiring
Container configuration and resolution
Practical implementation decisions

As a Principle:

Design philosophy favoring abstraction and loose coupling
Decision framework for where DI applies
Integration with SOLID and other design principles
Understanding of why injection matters

Neither perspective alone suffices. Technique without principle becomes mechanical ceremony. Principle without technique becomes good intent without delivery.

Key Takeaways

•DI is both technique and principle — Understand both perspectives for effective application.
•Technique answers 'how' — Constructor injection, setter injection, container configuration.
•Principle answers 'why' and 'when' — Loose coupling, testability, volatility assessment.
•Neither alone suffices — Mechanical DI misses the point; philosophical DI without technique doesn't ship.
•Apply selectively — Inject volatile, testable-needs, multi-implementation dependencies. Skip stable utilities.
•Let principle guide technique — Ask why before implementing how.

Page Complete

2 / 4