System Design (LLD)Setter Injection

Setter Injection: Providing Dependencies Through Mutator Methods

LevelIntermediate

Duration50 mins

TopicSetter Injection

4 / 4

When to Use Setter Injection

Making the Right Choice

We've explored setter injection's mechanics, its patterns for optional dependencies, and its trade-offs. Now we synthesize this knowledge into a practical decision framework.

The goal isn't to declare one style "better" than the other—both constructor and setter injection are tools with appropriate use cases. The goal is to develop the judgment to choose correctly for each situation.

This page provides:

A decision tree for choosing injection styles
Clear criteria for when setter injection is appropriate
Real-world scenarios with recommended approaches
A checklist you can apply to your own code

What You Will Learn

By the end of this page, you will have a clear decision framework for choosing between constructor and setter injection, understand the specific scenarios where setter injection is the right choice, be able to apply these principles to your own codebase, and know how to refactor between injection styles when requirements change.

The Decision Framework: A Systematic Approach

When deciding how to inject a dependency, work through these questions in order. The first "yes" answer determines the recommendation:

Question 1: Is the dependency required for the class to function correctly?

If YES → Constructor injection (stop here)
If NO → Continue to Question 2

Question 2: Is the dependency truly optional—can the class provide value without it?

If YES → Setter injection is appropriate
If NO → Re-evaluate Question 1

Question 3: Does the framework require setter injection?

If YES → Use setter injection but validate in lifecycle hooks
If NO → Continue to Question 4

Question 4: Is there a circular dependency that prevents constructor injection?

If YES → Consider refactoring first; if not possible, use setter injection with careful documentation
If NO → Default to constructor injection

The Default Rule:

When in doubt, use constructor injection. Its compile-time safety catches errors earlier.

DecisionFrameworkDiagram.txt

Decision Tree

                    ┌─────────────────────────────┐
                    │  Is the dependency required │
                    │  for core functionality?    │
                    └─────────────┬───────────────┘
                                  │
              ┌─────YES──────────┴──────────NO───────┐
              │                                       │
              ▼                                       ▼
    ┌─────────────────┐              ┌────────────────────────────┐
    │   CONSTRUCTOR   │              │ Can the class work without │
    │   INJECTION     │              │ this dependency?           │
    │   (Required)    │              └───────────┬────────────────┘
    └─────────────────┘                          │
                                   ┌────YES──────┴──────NO────────┐
                                   │                               │
                                   ▼                               ▼
                      ┌─────────────────────┐         ┌─────────────────────┐
                      │  SETTER INJECTION   │         │   Re-evaluate:      │
                      │  (Optional)         │         │   Is it actually    │
                      └─────────────────────┘         │   required?         │
                                                      └─────────────────────┘
 
    Common Patterns:
    ┌─────────────────────────────────────────────────────────────────────┐
    │                                                                     │
    │  CONSTRUCTOR INJECTION                 SETTER INJECTION             │
    │  ✓ Database connections                ✓ Logging                    │
    │  ✓ External APIs                       ✓ Metrics/Telemetry          │
    │  ✓ Core business services              ✓ Caching                    │
    │  ✓ Configuration                       ✓ Auditing                   │
    │  ✓ Required repositories               ✓ Notifications              │
    │                                        ✓ Plugin systems             │
    │                                                                     │
    └─────────────────────────────────────────────────────────────────────┘

Scenario-Based Guidance

Let's apply the decision framework to common real-world scenarios:

Scenario: Building a UserRepository

A UserRepository needs:

Database connection (for persistence)
Logger (for debugging)
Metrics collector (for monitoring)
Cache (for performance)

Analysis:

Dependency	Required?	Recommendation	Rationale
Database connection	Yes	Constructor	Repository cannot function without database
Logger	No	Setter or Null Object	Queries work without logging
Metrics collector	No	Setter or Null Object	Queries work without metrics
Cache	It depends	Constructor or Setter	If caching is core strategy: constructor. If optional optimization: setter

TypeScript
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
// Recommended implementation
class UserRepository {
    // Constructor for required dependencies
    constructor(
        private readonly database: IDatabase,
        private readonly cache: ICache // If caching is a core strategy
    ) {
        if (!database) throw new Error("Database is required");
        if (!cache) throw new Error("Cache is required");
    }
 
    // Setters for optional dependencies
    private logger: ILogger = new NullLogger();
    private metrics: IMetrics = new NullMetrics();
 
    setLogger(logger: ILogger): this {
        this.logger = logger;
        return this;
    }
 
    setMetrics(metrics: IMetrics): this {
        this.metrics = metrics;
        return this;
    }
 
    async findById(id: string): Promise<User | null> {
        this.logger.debug(`Finding user: ${id}`);
        const start = Date.now();
 
        const cached = await this.cache.get(`user:${id}`);
        if (cached) {
            this.metrics.increment('user.cache.hit');
            return cached;
        }
 
        this.metrics.increment('user.cache.miss');
        const user = await this.database.query(`SELECT * FROM users WHERE id = ?`, [id]);
        
        if (user) {
            await this.cache.set(`user:${id}`, user, { ttl: 3600 });
        }
 
        this.metrics.timing('user.findById', Date.now() - start);
        return user;
    }
}

The Hybrid Approach: Combining Constructor and Setter Injection

In practice, the cleanest designs often use both injection styles—constructor injection for required dependencies and setter injection for optional ones. This hybrid approach captures the benefits of both:

Compile-time safety for required dependencies
Flexibility for optional enhancements
Clear API that distinguishes required from optional
Default behavior that works without configuration

HybridApproachExample.ts
TypeScript
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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
/**
 * DocumentProcessor demonstrates the hybrid approach:
 * - Required dependencies via constructor
 * - Optional dependencies via setters with null object defaults
 */
class DocumentProcessor {
    // ══════════════════════════════════════════════════════════════════
    // REQUIRED DEPENDENCIES (via constructor)
    // These are essential - the class cannot function without them
    // ══════════════════════════════════════════════════════════════════
    private readonly storage: IDocumentStorage;
    private readonly parser: IDocumentParser;
    private readonly validator: IDocumentValidator;
 
    // ══════════════════════════════════════════════════════════════════
    // OPTIONAL DEPENDENCIES (via setters, with null object defaults)
    // These enhance functionality but aren't required for core operation
    // ══════════════════════════════════════════════════════════════════
    private logger: ILogger = new NullLogger();
    private metrics: IMetrics = new NullMetrics();
    private cache: IDocumentCache = new NullCache();
    private notifier: IProcessingNotifier = new NullNotifier();
 
    // Constructor enforces required dependencies
    constructor(
        storage: IDocumentStorage,
        parser: IDocumentParser,
        validator: IDocumentValidator
    ) {
        // Validate required dependencies
        if (!storage) throw new Error("DocumentStorage is required");
        if (!parser) throw new Error("DocumentParser is required");
        if (!validator) throw new Error("DocumentValidator is required");
 
        this.storage = storage;
        this.parser = parser;
        this.validator = validator;
    }
 
    // Fluent setters for optional dependencies
    withLogger(logger: ILogger): this {
        this.logger = logger;
        return this;
    }
 
    withMetrics(metrics: IMetrics): this {
        this.metrics = metrics;
        return this;
    }
 
    withCache(cache: IDocumentCache): this {
        this.cache = cache;
        return this;
    }
 
    withNotifier(notifier: IProcessingNotifier): this {
        this.notifier = notifier;
        return this;
    }
 
    // Core processing logic - uses all dependencies,
    // but optional ones are safe to use (null objects do nothing)
    async processDocument(documentId: string): Promise<ProcessingResult> {
        const startTime = Date.now();
        this.logger.info(`Starting document processing: ${documentId}`);
 
        try {
            // Check cache first (no-op if NullCache)
            const cached = this.cache.get(documentId);
            if (cached) {
                this.logger.debug("Cache hit");
                this.metrics.increment("document.cache.hit");
                return cached;
            }
            this.metrics.increment("document.cache.miss");
 
            // Fetch and parse (required operations)
            const rawDocument = await this.storage.fetch(documentId);
            const parsedDocument = await this.parser.parse(rawDocument);
 
            // Validate (required operation)
            const validation = await this.validator.validate(parsedDocument);
            if (!validation.isValid) {
                this.metrics.increment("document.validation.failed");
                return { success: false, errors: validation.errors };
            }
 
            // Create result
            const result: ProcessingResult = {
                success: true,
                documentId,
                processedAt: new Date(),
                data: parsedDocument
            };
 
            // Cache result (no-op if NullCache)
            this.cache.set(documentId, result);
 
            // Record metrics (no-op if NullMetrics)
            this.metrics.timing("document.process.duration", Date.now() - startTime);
            this.metrics.increment("document.processed");
 
            // Notify (no-op if NullNotifier)
            await this.notifier.notifyProcessingComplete(documentId, result);
 
            return result;
 
        } catch (error) {
            this.logger.error(`Processing failed: ${error}`);
            this.metrics.increment("document.process.error");
            throw error;
        }
    }
}
 
// ═══════════════════════════════════════════════════════════════════════════
// USAGE EXAMPLES
// ═══════════════════════════════════════════════════════════════════════════
 
// Minimal configuration - only required dependencies
const minimalProcessor = new DocumentProcessor(
    new S3DocumentStorage(s3Client),
    new PdfParser(),
    new SchemaValidator(documentSchema)
);
// Works! Uses null objects for optional dependencies
 
// Full configuration - all optional dependencies
const fullyConfiguredProcessor = new DocumentProcessor(
    new S3DocumentStorage(s3Client),
    new PdfParser(),
    new SchemaValidator(documentSchema)
)
.withLogger(new WinstonLogger())
.withMetrics(new DatadogMetrics())
.withCache(new RedisDocumentCache())
.withNotifier(new SlackNotifier());
// Works! Uses all configured enhancements
 
// Selective configuration - only logging and metrics
const observableProcessor = new DocumentProcessor(
    new S3DocumentStorage(s3Client),
    new PdfParser(),
    new SchemaValidator(documentSchema)
)
.withLogger(new WinstonLogger())
.withMetrics(new DatadogMetrics());
// Works! Logging and metrics enabled, cache and notifier are no-ops

The 'with' Prefix Convention

Notice the withLogger, withCache naming convention instead of setLogger, setCache. This 'with' prefix suggests immutability (even though the object is technically mutable) and reads more naturally in fluent chains. It's a common convention for builder-style configuration.

Refactoring Between Injection Styles

Requirements change. A dependency that was optional becomes required, or a required dependency becomes optional. Here's how to safely refactor between injection styles:

From Setter to Constructor (Making Optional Dependency Required):

SetterToConstructor.ts
TypeScript
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
// BEFORE: Cache was optional
class ProductService {
    private cache: ICache | null = null;
 
    setCache(cache: ICache): void {
        this.cache = cache;
    }
 
    async getProduct(id: string): Promise<Product> {
        // Optional cache usage
        if (this.cache) {
            const cached = await this.cache.get(id);
            if (cached) return cached;
        }
        
        const product = await this.fetchFromDb(id);
        
        this.cache?.set(id, product);
        
        return product;
    }
}
 
// AFTER: Cache is now required (performance is critical)
class ProductService {
    // Now required in constructor
    constructor(
        private readonly database: IDatabase,
        private readonly cache: ICache  // NEW: required parameter
    ) {
        if (!cache) throw new Error("Cache is required");
    }
 
    async getProduct(id: string): Promise<Product> {
        // No null checks needed - cache is guaranteed
        const cached = await this.cache.get(id);
        if (cached) return cached;
        
        const product = await this.fetchFromDb(id);
        await this.cache.set(id, product);
        
        return product;
    }
}
 
// Migration: Update all instantiation sites
// Find: new ProductService(database)
// Replace: new ProductService(database, cacheInstance)
 
// If you had: productService.setCache(cache)
// Remove those calls - cache is now in constructor

From Constructor to Setter (Making Required Dependency Optional):

ConstructorToSetter.ts
TypeScript
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
// BEFORE: Audit logger was required
class TransactionProcessor {
    constructor(
        private readonly ledger: ILedger,
        private readonly auditLogger: IAuditLogger  // Required
    ) {}
 
    async processTransaction(tx: Transaction): Promise<void> {
        await this.auditLogger.logStart(tx);
        await this.ledger.record(tx);
        await this.auditLogger.logComplete(tx);
    }
}
 
// AFTER: Audit logging is now optional (some deployments don't need it)
class TransactionProcessor {
    // Only ledger in constructor
    constructor(private readonly ledger: ILedger) {}
 
    // Audit logger is now optional with null object default
    private auditLogger: IAuditLogger = new NullAuditLogger();
 
    setAuditLogger(logger: IAuditLogger): this {
        this.auditLogger = logger;
        return this;
    }
 
    async processTransaction(tx: Transaction): Promise<void> {
        // Null object handles missing auditing gracefully
        await this.auditLogger.logStart(tx);
        await this.ledger.record(tx);
        await this.auditLogger.logComplete(tx);
    }
}
 
// Migration: Update instantiation sites
// Find: new TransactionProcessor(ledger, auditLogger)
// Replace: new TransactionProcessor(ledger).setAuditLogger(auditLogger)
// Or, if auditing not needed: new TransactionProcessor(ledger)

Migration Strategy

When refactoring injection styles in a large codebase, consider using the constructor parameter with a default value as a transitional step. This maintains backward compatibility while you update call sites: constructor(ledger: ILedger, auditLogger?: IAuditLogger)

Decision Checklist: A Practical Reference

Use this checklist when deciding between constructor and setter injection for a dependency:

Use Constructor Injection When...

•☑ The class cannot perform its core function without this dependency
•☑ Every method in the class uses this dependency
•☑ The dependency should never change after construction
•☑ You want compile-time verification of dependency presence
•☑ The dependency has complex or expensive initialization
•☑ Thread-safety with immutable references is important
•☑ You want the API to clearly communicate requirements

Use Setter Injection When...

•☑ The class works correctly without this dependency
•☑ The dependency enhances but isn't essential (logging, metrics, caching)
•☑ Different deployments need different configurations
•☑ The framework requires setter injection
•☑ You need to resolve circular dependencies (and can't refactor them away)
•☑ The dependency may be changed at runtime (rare but valid)
•☑ You're implementing a plugin or extension system

Avoid Setter Injection When...

•☒ You're using it just to reduce constructor parameters (refactor instead)
•☒ The dependency is actually required but you want 'flexibility'
•☒ You'd need null checks scattered throughout the class
•☒ Missing the dependency would cause subtle, hard-to-debug failures
•☒ The class has many setter-injected dependencies with complex temporal coupling

Module Summary: Mastering Setter Injection

We've completed our deep dive into setter injection. Let's consolidate everything we've learned across this module:

Module Key Takeaways

•Mechanics — Setter injection provides dependencies via mutator methods after construction, creating a two-phase lifecycle
•Optional Dependencies Pattern — Setter injection's sweet spot is optional dependencies that enhance but aren't required for core functionality
•Trade-offs — Flexibility comes at the cost of compile-time safety, immutability, and API clarity. Understand what you're trading.
•Null Object Pattern — Pre-initialize with null objects to eliminate null checks and simplify code
•Hybrid Approach — Combine constructor injection for required and setter injection for optional dependencies
•Decision Framework — Default to constructor injection; use setter injection for genuinely optional dependencies or framework requirements

The Guiding Principles:

Constructor injection by default, setter injection by exception.

Required in constructor, optional in setters.

When using setters, prefer null objects over null checks.

With these principles internalized, you can make informed decisions about dependency injection in any codebase. Setter injection is a valuable tool—but like any tool, it's most effective when used appropriately.

Module Complete

You have mastered setter injection—understanding when to use it, how to implement it correctly, and what trade-offs it entails. You can now confidently choose between constructor and setter injection based on dependency characteristics, and you understand the patterns that make setter injection safe and maintainable. In the next module, we'll explore Interface Injection, the third injection style.

4 / 4

Loading learning content...

System Design (LLD)Setter Injection

Setter Injection: Providing Dependencies Through Mutator Methods

LevelIntermediate

Duration50 mins

TopicSetter Injection

4 / 4

When to Use Setter Injection

Making the Right Choice

We've explored setter injection's mechanics, its patterns for optional dependencies, and its trade-offs. Now we synthesize this knowledge into a practical decision framework.

This page provides:

A decision tree for choosing injection styles
Clear criteria for when setter injection is appropriate
Real-world scenarios with recommended approaches
A checklist you can apply to your own code

What You Will Learn

The Decision Framework: A Systematic Approach

When deciding how to inject a dependency, work through these questions in order. The first "yes" answer determines the recommendation:

Question 1: Is the dependency required for the class to function correctly?

If YES → Constructor injection (stop here)
If NO → Continue to Question 2

Question 2: Is the dependency truly optional—can the class provide value without it?

If YES → Setter injection is appropriate
If NO → Re-evaluate Question 1

Question 3: Does the framework require setter injection?

If YES → Use setter injection but validate in lifecycle hooks
If NO → Continue to Question 4

Question 4: Is there a circular dependency that prevents constructor injection?

If YES → Consider refactoring first; if not possible, use setter injection with careful documentation
If NO → Default to constructor injection

The Default Rule:

When in doubt, use constructor injection. Its compile-time safety catches errors earlier.

DecisionFrameworkDiagram.txt

Decision Tree

                    ┌─────────────────────────────┐
                    │  Is the dependency required │
                    │  for core functionality?    │
                    └─────────────┬───────────────┘
                                  │
              ┌─────YES──────────┴──────────NO───────┐
              │                                       │
              ▼                                       ▼
    ┌─────────────────┐              ┌────────────────────────────┐
    │   CONSTRUCTOR   │              │ Can the class work without │
    │   INJECTION     │              │ this dependency?           │
    │   (Required)    │              └───────────┬────────────────┘
    └─────────────────┘                          │
                                   ┌────YES──────┴──────NO────────┐
                                   │                               │
                                   ▼                               ▼
                      ┌─────────────────────┐         ┌─────────────────────┐
                      │  SETTER INJECTION   │         │   Re-evaluate:      │
                      │  (Optional)         │         │   Is it actually    │
                      └─────────────────────┘         │   required?         │
                                                      └─────────────────────┘
 
    Common Patterns:
    ┌─────────────────────────────────────────────────────────────────────┐
    │                                                                     │
    │  CONSTRUCTOR INJECTION                 SETTER INJECTION             │
    │  ✓ Database connections                ✓ Logging                    │
    │  ✓ External APIs                       ✓ Metrics/Telemetry          │
    │  ✓ Core business services              ✓ Caching                    │
    │  ✓ Configuration                       ✓ Auditing                   │
    │  ✓ Required repositories               ✓ Notifications              │
    │                                        ✓ Plugin systems             │
    │                                                                     │
    └─────────────────────────────────────────────────────────────────────┘

Scenario-Based Guidance

Let's apply the decision framework to common real-world scenarios:

Scenario: Building a UserRepository

A UserRepository needs:

Database connection (for persistence)
Logger (for debugging)
Metrics collector (for monitoring)
Cache (for performance)

Analysis:

Dependency	Required?	Recommendation	Rationale
Database connection	Yes	Constructor	Repository cannot function without database
Logger	No	Setter or Null Object	Queries work without logging
Metrics collector	No	Setter or Null Object	Queries work without metrics
Cache	It depends	Constructor or Setter	If caching is core strategy: constructor. If optional optimization: setter

TypeScript
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
// Recommended implementation
class UserRepository {
    // Constructor for required dependencies
    constructor(
        private readonly database: IDatabase,
        private readonly cache: ICache // If caching is a core strategy
    ) {
        if (!database) throw new Error("Database is required");
        if (!cache) throw new Error("Cache is required");
    }
 
    // Setters for optional dependencies
    private logger: ILogger = new NullLogger();
    private metrics: IMetrics = new NullMetrics();
 
    setLogger(logger: ILogger): this {
        this.logger = logger;
        return this;
    }
 
    setMetrics(metrics: IMetrics): this {
        this.metrics = metrics;
        return this;
    }
 
    async findById(id: string): Promise<User | null> {
        this.logger.debug(`Finding user: ${id}`);
        const start = Date.now();
 
        const cached = await this.cache.get(`user:${id}`);
        if (cached) {
            this.metrics.increment('user.cache.hit');
            return cached;
        }
 
        this.metrics.increment('user.cache.miss');
        const user = await this.database.query(`SELECT * FROM users WHERE id = ?`, [id]);
        
        if (user) {
            await this.cache.set(`user:${id}`, user, { ttl: 3600 });
        }
 
        this.metrics.timing('user.findById', Date.now() - start);
        return user;
    }
}

The Hybrid Approach: Combining Constructor and Setter Injection

Compile-time safety for required dependencies
Flexibility for optional enhancements
Clear API that distinguishes required from optional
Default behavior that works without configuration

HybridApproachExample.ts
TypeScript
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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
/**
 * DocumentProcessor demonstrates the hybrid approach:
 * - Required dependencies via constructor
 * - Optional dependencies via setters with null object defaults
 */
class DocumentProcessor {
    // ══════════════════════════════════════════════════════════════════
    // REQUIRED DEPENDENCIES (via constructor)
    // These are essential - the class cannot function without them
    // ══════════════════════════════════════════════════════════════════
    private readonly storage: IDocumentStorage;
    private readonly parser: IDocumentParser;
    private readonly validator: IDocumentValidator;
 
    // ══════════════════════════════════════════════════════════════════
    // OPTIONAL DEPENDENCIES (via setters, with null object defaults)
    // These enhance functionality but aren't required for core operation
    // ══════════════════════════════════════════════════════════════════
    private logger: ILogger = new NullLogger();
    private metrics: IMetrics = new NullMetrics();
    private cache: IDocumentCache = new NullCache();
    private notifier: IProcessingNotifier = new NullNotifier();
 
    // Constructor enforces required dependencies
    constructor(
        storage: IDocumentStorage,
        parser: IDocumentParser,
        validator: IDocumentValidator
    ) {
        // Validate required dependencies
        if (!storage) throw new Error("DocumentStorage is required");
        if (!parser) throw new Error("DocumentParser is required");
        if (!validator) throw new Error("DocumentValidator is required");
 
        this.storage = storage;
        this.parser = parser;
        this.validator = validator;
    }
 
    // Fluent setters for optional dependencies
    withLogger(logger: ILogger): this {
        this.logger = logger;
        return this;
    }
 
    withMetrics(metrics: IMetrics): this {
        this.metrics = metrics;
        return this;
    }
 
    withCache(cache: IDocumentCache): this {
        this.cache = cache;
        return this;
    }
 
    withNotifier(notifier: IProcessingNotifier): this {
        this.notifier = notifier;
        return this;
    }
 
    // Core processing logic - uses all dependencies,
    // but optional ones are safe to use (null objects do nothing)
    async processDocument(documentId: string): Promise<ProcessingResult> {
        const startTime = Date.now();
        this.logger.info(`Starting document processing: ${documentId}`);
 
        try {
            // Check cache first (no-op if NullCache)
            const cached = this.cache.get(documentId);
            if (cached) {
                this.logger.debug("Cache hit");
                this.metrics.increment("document.cache.hit");
                return cached;
            }
            this.metrics.increment("document.cache.miss");
 
            // Fetch and parse (required operations)
            const rawDocument = await this.storage.fetch(documentId);
            const parsedDocument = await this.parser.parse(rawDocument);
 
            // Validate (required operation)
            const validation = await this.validator.validate(parsedDocument);
            if (!validation.isValid) {
                this.metrics.increment("document.validation.failed");
                return { success: false, errors: validation.errors };
            }
 
            // Create result
            const result: ProcessingResult = {
                success: true,
                documentId,
                processedAt: new Date(),
                data: parsedDocument
            };
 
            // Cache result (no-op if NullCache)
            this.cache.set(documentId, result);
 
            // Record metrics (no-op if NullMetrics)
            this.metrics.timing("document.process.duration", Date.now() - startTime);
            this.metrics.increment("document.processed");
 
            // Notify (no-op if NullNotifier)
            await this.notifier.notifyProcessingComplete(documentId, result);
 
            return result;
 
        } catch (error) {
            this.logger.error(`Processing failed: ${error}`);
            this.metrics.increment("document.process.error");
            throw error;
        }
    }
}
 
// ═══════════════════════════════════════════════════════════════════════════
// USAGE EXAMPLES
// ═══════════════════════════════════════════════════════════════════════════
 
// Minimal configuration - only required dependencies
const minimalProcessor = new DocumentProcessor(
    new S3DocumentStorage(s3Client),
    new PdfParser(),
    new SchemaValidator(documentSchema)
);
// Works! Uses null objects for optional dependencies
 
// Full configuration - all optional dependencies
const fullyConfiguredProcessor = new DocumentProcessor(
    new S3DocumentStorage(s3Client),
    new PdfParser(),
    new SchemaValidator(documentSchema)
)
.withLogger(new WinstonLogger())
.withMetrics(new DatadogMetrics())
.withCache(new RedisDocumentCache())
.withNotifier(new SlackNotifier());
// Works! Uses all configured enhancements
 
// Selective configuration - only logging and metrics
const observableProcessor = new DocumentProcessor(
    new S3DocumentStorage(s3Client),
    new PdfParser(),
    new SchemaValidator(documentSchema)
)
.withLogger(new WinstonLogger())
.withMetrics(new DatadogMetrics());
// Works! Logging and metrics enabled, cache and notifier are no-ops

The 'with' Prefix Convention

Refactoring Between Injection Styles

Requirements change. A dependency that was optional becomes required, or a required dependency becomes optional. Here's how to safely refactor between injection styles:

From Setter to Constructor (Making Optional Dependency Required):

SetterToConstructor.ts
TypeScript
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
// BEFORE: Cache was optional
class ProductService {
    private cache: ICache | null = null;
 
    setCache(cache: ICache): void {
        this.cache = cache;
    }
 
    async getProduct(id: string): Promise<Product> {
        // Optional cache usage
        if (this.cache) {
            const cached = await this.cache.get(id);
            if (cached) return cached;
        }
        
        const product = await this.fetchFromDb(id);
        
        this.cache?.set(id, product);
        
        return product;
    }
}
 
// AFTER: Cache is now required (performance is critical)
class ProductService {
    // Now required in constructor
    constructor(
        private readonly database: IDatabase,
        private readonly cache: ICache  // NEW: required parameter
    ) {
        if (!cache) throw new Error("Cache is required");
    }
 
    async getProduct(id: string): Promise<Product> {
        // No null checks needed - cache is guaranteed
        const cached = await this.cache.get(id);
        if (cached) return cached;
        
        const product = await this.fetchFromDb(id);
        await this.cache.set(id, product);
        
        return product;
    }
}
 
// Migration: Update all instantiation sites
// Find: new ProductService(database)
// Replace: new ProductService(database, cacheInstance)
 
// If you had: productService.setCache(cache)
// Remove those calls - cache is now in constructor

From Constructor to Setter (Making Required Dependency Optional):

ConstructorToSetter.ts
TypeScript
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
// BEFORE: Audit logger was required
class TransactionProcessor {
    constructor(
        private readonly ledger: ILedger,
        private readonly auditLogger: IAuditLogger  // Required
    ) {}
 
    async processTransaction(tx: Transaction): Promise<void> {
        await this.auditLogger.logStart(tx);
        await this.ledger.record(tx);
        await this.auditLogger.logComplete(tx);
    }
}
 
// AFTER: Audit logging is now optional (some deployments don't need it)
class TransactionProcessor {
    // Only ledger in constructor
    constructor(private readonly ledger: ILedger) {}
 
    // Audit logger is now optional with null object default
    private auditLogger: IAuditLogger = new NullAuditLogger();
 
    setAuditLogger(logger: IAuditLogger): this {
        this.auditLogger = logger;
        return this;
    }
 
    async processTransaction(tx: Transaction): Promise<void> {
        // Null object handles missing auditing gracefully
        await this.auditLogger.logStart(tx);
        await this.ledger.record(tx);
        await this.auditLogger.logComplete(tx);
    }
}
 
// Migration: Update instantiation sites
// Find: new TransactionProcessor(ledger, auditLogger)
// Replace: new TransactionProcessor(ledger).setAuditLogger(auditLogger)
// Or, if auditing not needed: new TransactionProcessor(ledger)

Migration Strategy

Decision Checklist: A Practical Reference

Use this checklist when deciding between constructor and setter injection for a dependency:

Use Constructor Injection When...

•☑ The class cannot perform its core function without this dependency
•☑ Every method in the class uses this dependency
•☑ The dependency should never change after construction
•☑ You want compile-time verification of dependency presence
•☑ The dependency has complex or expensive initialization
•☑ Thread-safety with immutable references is important
•☑ You want the API to clearly communicate requirements

Use Setter Injection When...

•☑ The class works correctly without this dependency
•☑ The dependency enhances but isn't essential (logging, metrics, caching)
•☑ Different deployments need different configurations
•☑ The framework requires setter injection
•☑ You need to resolve circular dependencies (and can't refactor them away)
•☑ The dependency may be changed at runtime (rare but valid)
•☑ You're implementing a plugin or extension system

Avoid Setter Injection When...

•☒ You're using it just to reduce constructor parameters (refactor instead)
•☒ The dependency is actually required but you want 'flexibility'
•☒ You'd need null checks scattered throughout the class
•☒ Missing the dependency would cause subtle, hard-to-debug failures
•☒ The class has many setter-injected dependencies with complex temporal coupling

Module Summary: Mastering Setter Injection

We've completed our deep dive into setter injection. Let's consolidate everything we've learned across this module:

Module Key Takeaways

•Mechanics — Setter injection provides dependencies via mutator methods after construction, creating a two-phase lifecycle
•Optional Dependencies Pattern — Setter injection's sweet spot is optional dependencies that enhance but aren't required for core functionality
•Trade-offs — Flexibility comes at the cost of compile-time safety, immutability, and API clarity. Understand what you're trading.
•Null Object Pattern — Pre-initialize with null objects to eliminate null checks and simplify code
•Hybrid Approach — Combine constructor injection for required and setter injection for optional dependencies
•Decision Framework — Default to constructor injection; use setter injection for genuinely optional dependencies or framework requirements

The Guiding Principles:

Constructor injection by default, setter injection by exception.

Required in constructor, optional in setters.

When using setters, prefer null objects over null checks.

Module Complete

4 / 4