Setter Injection - Learning Module

Loading content...

0/246

Optional Dependencies Pattern

When Dependencies Aren't Mandatory

Not all dependencies are created equal. Some collaborators are essential—without them, the class simply cannot perform its core function. A UserRepository needs a database connection to fetch users. An EmailSender needs SMTP credentials to send mail. These are mandatory dependencies, and they belong in the constructor.

But other dependencies enhance functionality without being essential. A logging framework improves observability but isn't required for business logic execution. A caching layer improves performance but the system works without it. A metrics collector enables monitoring but operations proceed without metrics.

These are optional dependencies, and they represent the sweet spot for setter injection. This page explores the Optional Dependencies Pattern—how to design classes that work correctly without their optional collaborators while gracefully enhancing functionality when those collaborators are provided.

What You Will Learn

By the end of this page, you will be able to distinguish truly optional dependencies from mandatory ones, design classes that degrade gracefully when optional dependencies are absent, implement the Optional Dependencies Pattern correctly, and understand the patterns that make optional dependency handling clean and maintainable.

Identifying Truly Optional Dependencies

The first challenge is correctly identifying which dependencies are optional. This seems straightforward, but developers frequently misclassify dependencies—either treating mandatory dependencies as optional (leading to runtime failures) or treating optional dependencies as mandatory (forcing unnecessary configuration).

The Litmus Test: Can the Class Fulfill Its Contract Without This Dependency?

Ask yourself: If this dependency is null, can the class still perform its core responsibility? Not at full capability—just its essential function.

If no: The dependency is mandatory. Use constructor injection.
If yes: The dependency may be optional. Consider setter injection.

Dependency Classification Examples
Class	Dependency	Mandatory?	Reasoning
UserRepository	Database Connection	Mandatory	Cannot fetch users without database access
UserRepository	Query Logger	Optional	Can fetch users without logging queries
PaymentProcessor	Payment Gateway	Mandatory	Cannot process payments without a gateway
PaymentProcessor	Fraud Detection Service	Often Optional	Can process payments, but with higher risk
EmailService	SMTP Connection	Mandatory	Cannot send emails without SMTP
EmailService	Template Engine	It Depends	Depends on whether raw text mode is acceptable
WebController	Request Handler	Mandatory	Cannot handle requests without a handler
WebController	Rate Limiter	Optional	Can handle requests without rate limiting
CacheManager	Primary Cache	Mandatory	A cache manager needs something to manage
CacheManager	Fallback Cache	Optional	Primary cache is sufficient; fallback enhances resilience

The 'It Depends' Trap

Some dependencies seem optional but actually aren't. A TemplateEngine might seem optional for an EmailService, but if your application only sends templated emails, then it's effectively mandatory. Always consider your actual use cases, not theoretical flexibility.

Common Categories of Optional Dependencies

Through experience, several categories of dependencies consistently qualify as optional:

Typically Optional Dependencies

•Logging — Operations proceed without logging; logging adds observability
•Metrics/Telemetry — Business logic works without metrics; metrics add monitoring
•Caching — Core function works (slowly); caching adds performance
•Auditing — Operations complete without auditing; auditing adds compliance
•Notifications — Core action succeeds without notification; notification adds user experience
•Analytics — Feature works without analytics; analytics adds insights
•Feature Flags — Code runs with defaults; feature flags add control
•Tracing — Requests complete without traces; tracing adds debugging capability

Typically Mandatory Dependencies

•Data Stores — Repositories need databases; services need data
•External Gateways — Payment processors need payment gateways
•Security Services — Auth handlers need identity providers
•Core Algorithms — Calculators need their calculation strategies
•Configuration — Services need their configuration to operate correctly
•Domain Services — Orchestrators need the services they orchestrate

The Optional Dependencies Pattern in Action

Let's implement a complete example that demonstrates the Optional Dependencies Pattern. We'll build an OrderService that has both mandatory dependencies (injected via constructor) and optional dependencies (injected via setters).

This realistic example shows how the patterns interact in production code:

OrderServiceOptionalDeps.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
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
// =====================================
// Interfaces for Dependencies
// =====================================
 
interface IOrderRepository {
    save(order: Order): Promise<Order>;
    findById(id: string): Promise<Order | null>;
}
 
interface IPaymentGateway {
    charge(amount: number, paymentMethod: PaymentMethod): Promise<PaymentResult>;
}
 
interface ILogger {
    debug(message: string, context?: Record<string, any>): void;
    info(message: string, context?: Record<string, any>): void;
    error(message: string, context?: Record<string, any>): void;
}
 
interface IMetricsCollector {
    increment(metric: string, tags?: Record<string, string>): void;
    timing(metric: string, durationMs: number, tags?: Record<string, string>): void;
}
 
interface IEventPublisher {
    publish(event: DomainEvent): Promise<void>;
}
 
interface IInventoryCache {
    getStock(productId: string): number | null;
    setStock(productId: string, quantity: number): void;
}
 
// =====================================
// The Order Service
// =====================================
 
class OrderService {
    // MANDATORY dependencies - injected via constructor
    private readonly orderRepository: IOrderRepository;
    private readonly paymentGateway: IPaymentGateway;
 
    // OPTIONAL dependencies - injected via setters
    private logger: ILogger | null = null;
    private metrics: IMetricsCollector | null = null;
    private eventPublisher: IEventPublisher | null = null;
    private inventoryCache: IInventoryCache | null = null;
 
    // Constructor requires mandatory dependencies
    constructor(
        orderRepository: IOrderRepository,
        paymentGateway: IPaymentGateway
    ) {
        // Validate mandatory dependencies
        if (!orderRepository) {
            throw new Error("OrderRepository is required");
        }
        if (!paymentGateway) {
            throw new Error("PaymentGateway is required");
        }
 
        this.orderRepository = orderRepository;
        this.paymentGateway = paymentGateway;
    }
 
    // Setters for optional dependencies
    setLogger(logger: ILogger): this {
        this.logger = logger;
        return this;
    }
 
    setMetrics(metrics: IMetricsCollector): this {
        this.metrics = metrics;
        return this;
    }
 
    setEventPublisher(eventPublisher: IEventPublisher): this {
        this.eventPublisher = eventPublisher;
        return this;
    }
 
    setInventoryCache(cache: IInventoryCache): this {
        this.inventoryCache = cache;
        return this;
    }
 
    // Core business method demonstrating graceful degradation
    async placeOrder(request: PlaceOrderRequest): Promise<OrderResult> {
        const startTime = Date.now();
        const orderId = this.generateOrderId();
 
        // Logging: Optional - skip gracefully if not configured
        this.logger?.info("Placing order", { orderId, customerId: request.customerId });
 
        try {
            // Step 1: Validate and calculate (uses optional cache for stock check)
            const orderItems = await this.validateOrderItems(request.items);
            const total = this.calculateTotal(orderItems);
 
            // Step 2: Process payment (uses mandatory payment gateway)
            this.logger?.debug("Processing payment", { orderId, amount: total });
            const paymentResult = await this.paymentGateway.charge(
                total,
                request.paymentMethod
            );
 
            if (!paymentResult.success) {
                // Metrics: Optional - record failure if configured
                this.metrics?.increment("orders.payment_failed", { 
                    reason: paymentResult.errorCode 
                });
                
                return {
                    success: false,
                    error: `Payment failed: ${paymentResult.errorMessage}`
                };
            }
 
            // Step 3: Create and save order (uses mandatory repository)
            const order = new Order(
                orderId,
                request.customerId,
                orderItems,
                total,
                paymentResult.transactionId
            );
 
            await this.orderRepository.save(order);
            this.logger?.info("Order saved", { orderId });
 
            // Step 4: Publish event (optional - non-critical operation)
            if (this.eventPublisher) {
                try {
                    await this.eventPublisher.publish(
                        new OrderPlacedEvent(order)
                    );
                    this.logger?.debug("Order event published", { orderId });
                } catch (publishError) {
                    // Event publishing failure is non-fatal
                    this.logger?.error("Failed to publish order event", { 
                        orderId, 
                        error: String(publishError) 
                    });
                }
            }
 
            // Step 5: Record metrics (optional)
            const duration = Date.now() - startTime;
            this.metrics?.timing("orders.place_duration", duration);
            this.metrics?.increment("orders.placed", { status: "success" });
 
            return {
                success: true,
                orderId: order.id,
                totalCharged: total
            };
 
        } catch (error) {
            this.logger?.error("Order placement failed", { 
                orderId, 
                error: String(error) 
            });
            this.metrics?.increment("orders.placed", { status: "error" });
            throw error;
        }
    }
 
    // Helper that uses optional inventory cache
    private async validateOrderItems(
        items: OrderItemRequest[]
    ): Promise<ValidatedOrderItem[]> {
        const validated: ValidatedOrderItem[] = [];
 
        for (const item of items) {
            // Try cache first if available
            let stockLevel = this.inventoryCache?.getStock(item.productId);
            
            if (stockLevel === null || stockLevel === undefined) {
                // Cache miss or no cache - fall back to direct check
                this.logger?.debug("Cache miss for inventory", { 
                    productId: item.productId 
                });
                stockLevel = await this.fetchStockFromDatabase(item.productId);
                
                // Update cache if available
                this.inventoryCache?.setStock(item.productId, stockLevel);
            }
 
            if (stockLevel < item.quantity) {
                throw new InsufficientStockError(item.productId, item.quantity, stockLevel);
            }
 
            validated.push({
                productId: item.productId,
                quantity: item.quantity,
                unitPrice: await this.getProductPrice(item.productId)
            });
        }
 
        return validated;
    }
 
    private calculateTotal(items: ValidatedOrderItem[]): number {
        return items.reduce(
            (sum, item) => sum + (item.unitPrice * item.quantity), 
            0
        );
    }
 
    private generateOrderId(): string {
        return `ORD-${Date.now()}-${Math.random().toString(36).substr(2, 9)}`;
    }
 
    private async fetchStockFromDatabase(productId: string): Promise<number> {
        // Simulated database call
        return 100;
    }
 
    private async getProductPrice(productId: string): Promise<number> {
        // Simulated price lookup
        return 29.99;
    }
}

Key Observations from the Implementation:

Constructor for mandatory, setters for optional — The constructor signature clearly documents what's required. Setters indicate what's configurable.
Fluent setters — Returning this enables chained configuration for better readability.
Graceful degradation everywhere — Optional usage is wrapped in null-safe access (?.) or explicit checks.
No silent failures for critical paths — While optional dependencies are skipped gracefully, errors in core operations (payment, persistence) are propagated.
Logging errors in optional operations — When event publishing fails, we log the error but don't fail the order placement.

Graceful Degradation Strategies

When an optional dependency is absent, the class must degrade gracefully—continuing to function while simply lacking the enhanced capability. Let's explore the strategies for achieving this gracefully:

Strategy 1: Silent Skip

The simplest approach: if the dependency isn't there, don't perform the operation. Best for truly fire-and-forget operations like logging or metrics.

SilentSkipStrategy.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
class DocumentProcessor {
    private auditLogger: IAuditLogger | null = null;
 
    setAuditLogger(logger: IAuditLogger): void {
        this.auditLogger = logger;
    }
 
    processDocument(doc: Document): ProcessResult {
        // Silent skip - uses optional chaining
        this.auditLogger?.logAccess(doc.id, "process");
 
        // Core processing - always happens
        const result = this.doProcessing(doc);
 
        // Silent skip - no indication that auditing didn't happen
        this.auditLogger?.logCompletion(doc.id, "process", result.status);
 
        return result;
    }
}

Strategy 2: Default/Fallback Behavior

When the optional dependency would provide a value or make a decision, use a sensible default when it's absent:

FallbackBehaviorStrategy.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
interface IPricingStrategy {
    calculatePrice(basePrice: number, customer: Customer): number;
}
 
class ProductService {
    private pricingStrategy: IPricingStrategy | null = null;
 
    setPricingStrategy(strategy: IPricingStrategy): void {
        this.pricingStrategy = strategy;
    }
 
    getPrice(productId: string, customer: Customer): number {
        const basePrice = this.getBasePrice(productId);
 
        // Use strategy if available, otherwise use default (no discount)
        if (this.pricingStrategy) {
            return this.pricingStrategy.calculatePrice(basePrice, customer);
        }
 
        // Default behavior: return base price unchanged
        return basePrice;
    }
 
    getBasePrice(productId: string): number {
        // Fetch from database
        return 99.99;
    }
}
 
// Without pricing strategy: all customers pay base price
const basicService = new ProductService();
console.log(basicService.getPrice("PROD-1", vipCustomer)); // 99.99
 
// With pricing strategy: VIP customers get discounts
const advancedService = new ProductService();
advancedService.setPricingStrategy(new TieredPricingStrategy());
console.log(advancedService.getPrice("PROD-1", vipCustomer)); // 79.99

Strategy 3: Try-Catch Isolation

For optional operations that might fail, wrap them in try-catch to prevent failures from affecting the main operation:

TryCatchIsolationStrategy.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
interface INotificationService {
    sendNotification(userId: string, message: string): Promise<void>;
}
 
class OrderCompletionHandler {
    private notificationService: INotificationService | null = null;
    private analyticsService: IAnalyticsService | null = null;
 
    setNotificationService(service: INotificationService): void {
        this.notificationService = service;
    }
 
    setAnalyticsService(service: IAnalyticsService): void {
        this.analyticsService = service;
    }
 
    async handleOrderCompleted(order: Order): Promise<void> {
        // Critical: Update order status (will throw if it fails)
        await this.updateOrderStatus(order, "completed");
 
        // Optional: Send notification
        // Isolated in try-catch - failure doesn't affect order completion
        if (this.notificationService) {
            try {
                await this.notificationService.sendNotification(
                    order.customerId,
                    `Your order ${order.id} has been completed!`
                );
            } catch (error) {
                // Log but don't fail the operation
                console.error("Failed to send notification:", error);
                // Optionally: queue for retry, increment failure metric, etc.
            }
        }
 
        // Optional: Record analytics
        if (this.analyticsService) {
            try {
                await this.analyticsService.recordEvent("order_completed", {
                    orderId: order.id,
                    total: order.total,
                    itemCount: order.items.length
                });
            } catch (error) {
                console.error("Failed to record analytics:", error);
            }
        }
    }
 
    private async updateOrderStatus(order: Order, status: string): Promise<void> {
        // Critical database update
    }
}

Strategy 4: Null Object Default

Pre-initialize with a null object implementation so the class never needs null checks. The null object does nothing but satisfies the interface:

NullObjectDefaultStrategy.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
// Null Object implementations
class NullLogger implements ILogger {
    debug(message: string, context?: any): void { /* no-op */ }
    info(message: string, context?: any): void { /* no-op */ }
    error(message: string, context?: any): void { /* no-op */ }
}
 
class NullMetrics implements IMetricsCollector {
    increment(metric: string, tags?: any): void { /* no-op */ }
    timing(metric: string, ms: number, tags?: any): void { /* no-op */ }
}
 
class NullCache<T> implements ICache<T> {
    get(key: string): T | undefined { return undefined; }
    set(key: string, value: T): void { /* no-op */ }
    delete(key: string): void { /* no-op */ }
}
 
// Service uses null objects as defaults
class ReportGenerator {
    // Pre-initialized with null objects - NEVER null
    private logger: ILogger = new NullLogger();
    private metrics: IMetricsCollector = new NullMetrics();
    private cache: ICache<Report> = new NullCache();
 
    // Setters replace the null objects with real implementations
    setLogger(logger: ILogger): void {
        this.logger = logger;
    }
 
    setMetrics(metrics: IMetricsCollector): void {
        this.metrics = metrics;
    }
 
    setCache(cache: ICache<Report>): void {
        this.cache = cache;
    }
 
    async generateReport(params: ReportParams): Promise<Report> {
        const start = Date.now();
 
        // No null checks needed - null objects handle calls safely
        this.logger.info("Generating report", params);
 
        // Check cache (null cache always returns undefined)
        const cached = this.cache.get(params.cacheKey);
        if (cached) {
            this.logger.debug("Cache hit");
            this.metrics.increment("reports.cache_hit");
            return cached;
        }
 
        // Generate report
        this.metrics.increment("reports.cache_miss");
        const report = await this.buildReport(params);
 
        // Cache result (null cache ignores the set)
        this.cache.set(params.cacheKey, report);
 
        // Record timing
        this.metrics.timing("reports.generation_time", Date.now() - start);
        this.logger.info("Report generated", { id: report.id });
 
        return report;
    }
 
    private async buildReport(params: ReportParams): Promise<Report> {
        // Report generation logic
        return new Report(params);
    }
}
 
// Clean usage - no optional dependencies cluttering the code
const generator = new ReportGenerator();
const report = await generator.generateReport(params); // Works with all null objects
 
// Production usage - inject real implementations
generator.setLogger(new WinstonLogger());
generator.setMetrics(new DatadogMetrics());
generator.setCache(new RedisCache());

The Null Object Pattern Advantage

Using null objects as defaults completely eliminates null checks from the class's business logic. The code reads as if all dependencies are always present, making it cleaner and less error-prone. This is the recommended approach when you have multiple optional dependencies.

Configuration Patterns for Optional Dependencies

How optional dependencies get injected varies by architecture. Let's explore common configuration patterns:

Pattern 1: Manual Configuration in Composition Root

Explicitly configure optional dependencies during application startup:

ManualConfiguration.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
// composition-root.ts
// This is where you wire up your application
 
function configureApplication(config: AppConfig): AppContainer {
    // Create mandatory dependencies
    const database = new PostgresDatabase(config.databaseUrl);
    const paymentGateway = new StripeGateway(config.stripeApiKey);
 
    // Create the core service with mandatory dependencies
    const orderService = new OrderService(
        new OrderRepository(database),
        paymentGateway
    );
 
    // Configure optional dependencies based on environment/config
    if (config.logging.enabled) {
        const logger = new WinstonLogger(config.logging.level);
        orderService.setLogger(logger);
    }
 
    if (config.metrics.enabled) {
        const metrics = new DatadogMetrics(config.metrics.apiKey);
        orderService.setMetrics(metrics);
    }
 
    if (config.events.enabled) {
        const eventPublisher = new KafkaEventPublisher(config.events.brokers);
        orderService.setEventPublisher(eventPublisher);
    }
 
    if (config.cache.enabled) {
        const cache = new RedisCache(config.cache.url);
        orderService.setInventoryCache(new InventoryCacheAdapter(cache));
    }
 
    return { orderService };
}
 
// Different configurations for different environments
const devConfig: AppConfig = {
    logging: { enabled: true, level: "debug" },
    metrics: { enabled: false },          // No metrics in dev
    events: { enabled: false },           // No events in dev
    cache: { enabled: false },            // No cache in dev
    // ...
};
 
const prodConfig: AppConfig = {
    logging: { enabled: true, level: "info" },
    metrics: { enabled: true, apiKey: "xxx" },
    events: { enabled: true, brokers: ["kafka:9092"] },
    cache: { enabled: true, url: "redis://cache:6379" },
    // ...
};

Pattern 2: Framework-Based Configuration

DI frameworks often support optional injection natively:

FrameworkConfiguration.ts
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
// NestJS example with optional injection
import { Injectable, Optional, Inject } from '@nestjs/common';
 
@Injectable()
export class OrderService {
    constructor(
        // Required - will throw if not registered
        private readonly orderRepository: OrderRepository,
        private readonly paymentGateway: PaymentGateway,
        
        // Optional - null if not registered
        @Optional() @Inject('LOGGER') 
        private readonly logger?: ILogger,
        
        @Optional() @Inject('METRICS')
        private readonly metrics?: IMetricsCollector,
    ) {}
 
    async placeOrder(request: PlaceOrderRequest): Promise<OrderResult> {
        this.logger?.info("Placing order");
        
        // ... business logic ...
        
        this.metrics?.increment("orders.placed");
        return result;
    }
}
 
// Module registration
@Module({
    providers: [
        OrderRepository,
        PaymentGateway,
        // These may or may not be registered
        // {
        //     provide: 'LOGGER',
        //     useClass: WinstonLogger
        // },
    ],
})
export class OrderModule {}

Pattern 3: Builder Pattern for Complex Configuration

When many optional dependencies exist, a builder provides a clean configuration API:

BuilderPatternConfiguration.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
class OrderServiceBuilder {
    private orderRepository: IOrderRepository | null = null;
    private paymentGateway: IPaymentGateway | null = null;
    private logger: ILogger | null = null;
    private metrics: IMetricsCollector | null = null;
    private eventPublisher: IEventPublisher | null = null;
    private cache: IInventoryCache | null = null;
 
    // Required dependencies (must be called)
    withOrderRepository(repo: IOrderRepository): this {
        this.orderRepository = repo;
        return this;
    }
 
    withPaymentGateway(gateway: IPaymentGateway): this {
        this.paymentGateway = gateway;
        return this;
    }
 
    // Optional dependencies (may be called)
    withLogger(logger: ILogger): this {
        this.logger = logger;
        return this;
    }
 
    withMetrics(metrics: IMetricsCollector): this {
        this.metrics = metrics;
        return this;
    }
 
    withEventPublisher(publisher: IEventPublisher): this {
        this.eventPublisher = publisher;
        return this;
    }
 
    withCache(cache: IInventoryCache): this {
        this.cache = cache;
        return this;
    }
 
    build(): OrderService {
        // Validate required dependencies
        if (!this.orderRepository) {
            throw new Error("OrderRepository is required");
        }
        if (!this.paymentGateway) {
            throw new Error("PaymentGateway is required");
        }
 
        // Create service with required dependencies
        const service = new OrderService(
            this.orderRepository,
            this.paymentGateway
        );
 
        // Inject optional dependencies
        if (this.logger) {
            service.setLogger(this.logger);
        }
        if (this.metrics) {
            service.setMetrics(this.metrics);
        }
        if (this.eventPublisher) {
            service.setEventPublisher(this.eventPublisher);
        }
        if (this.cache) {
            service.setCache(this.cache);
        }
 
        return service;
    }
}
 
// Clean, readable configuration
const orderService = new OrderServiceBuilder()
    .withOrderRepository(new OrderRepository(db))
    .withPaymentGateway(new StripeGateway(apiKey))
    .withLogger(new ConsoleLogger())
    .withMetrics(new DatadogMetrics())
    // Note: Event publisher and cache are not configured
    .build();

Testing Classes with Optional Dependencies

Optional dependencies create interesting testing considerations. You need to test that the class works correctly in multiple configurations:

Without any optional dependencies (minimal configuration)
With all optional dependencies (full configuration)
With various combinations (realistic production scenarios)

Let's see how to write comprehensive tests:

OptionalDependencyTests.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
describe("OrderService", () => {
    // Mock mandatory dependencies (always needed)
    let mockOrderRepo: jest.Mocked<IOrderRepository>;
    let mockPaymentGateway: jest.Mocked<IPaymentGateway>;
    
    // Mock optional dependencies (sometimes needed)
    let mockLogger: jest.Mocked<ILogger>;
    let mockMetrics: jest.Mocked<IMetricsCollector>;
    let mockEventPublisher: jest.Mocked<IEventPublisher>;
 
    beforeEach(() => {
        // Set up mandatory mocks
        mockOrderRepo = {
            save: jest.fn().mockResolvedValue(/* saved order */),
            findById: jest.fn()
        };
        mockPaymentGateway = {
            charge: jest.fn().mockResolvedValue({ success: true, transactionId: "tx-123" })
        };
        
        // Set up optional mocks
        mockLogger = {
            debug: jest.fn(),
            info: jest.fn(),
            error: jest.fn()
        };
        mockMetrics = {
            increment: jest.fn(),
            timing: jest.fn()
        };
        mockEventPublisher = {
            publish: jest.fn().mockResolvedValue(undefined)
        };
    });
 
    describe("with minimal configuration (no optional dependencies)", () => {
        let service: OrderService;
 
        beforeEach(() => {
            // Only mandatory dependencies
            service = new OrderService(mockOrderRepo, mockPaymentGateway);
        });
 
        it("should place order successfully", async () => {
            const result = await service.placeOrder(validOrderRequest);
            
            expect(result.success).toBe(true);
            expect(mockPaymentGateway.charge).toHaveBeenCalled();
            expect(mockOrderRepo.save).toHaveBeenCalled();
        });
 
        it("should not throw when logging is not configured", async () => {
            await expect(service.placeOrder(validOrderRequest))
                .resolves.not.toThrow();
        });
 
        it("should not throw when metrics are not configured", async () => {
            await expect(service.placeOrder(validOrderRequest))
                .resolves.not.toThrow();
        });
    });
 
    describe("with full configuration (all optional dependencies)", () => {
        let service: OrderService;
 
        beforeEach(() => {
            service = new OrderService(mockOrderRepo, mockPaymentGateway);
            service.setLogger(mockLogger);
            service.setMetrics(mockMetrics);
            service.setEventPublisher(mockEventPublisher);
        });
 
        it("should log order placement", async () => {
            await service.placeOrder(validOrderRequest);
            
            expect(mockLogger.info).toHaveBeenCalledWith(
                "Placing order",
                expect.any(Object)
            );
        });
 
        it("should record metrics", async () => {
            await service.placeOrder(validOrderRequest);
            
            expect(mockMetrics.increment).toHaveBeenCalledWith(
                "orders.placed",
                expect.objectContaining({ status: "success" })
            );
        });
 
        it("should publish domain event", async () => {
            await service.placeOrder(validOrderRequest);
            
            expect(mockEventPublisher.publish).toHaveBeenCalledWith(
                expect.any(OrderPlacedEvent)
            );
        });
    });
 
    describe("resilience with optional dependencies", () => {
        it("should succeed even if event publishing fails", async () => {
            const service = new OrderService(mockOrderRepo, mockPaymentGateway);
            
            const failingPublisher = {
                publish: jest.fn().mockRejectedValue(new Error("Kafka unavailable"))
            };
            service.setEventPublisher(failingPublisher);
            service.setLogger(mockLogger);
 
            const result = await service.placeOrder(validOrderRequest);
 
            // Order should still succeed
            expect(result.success).toBe(true);
            
            // Error should be logged
            expect(mockLogger.error).toHaveBeenCalledWith(
                "Failed to publish order event",
                expect.any(Object)
            );
        });
 
        it("should work when logger is set to null after being configured", async () => {
            const service = new OrderService(mockOrderRepo, mockPaymentGateway);
            service.setLogger(mockLogger);
            
            // Some frameworks might set dependencies to null
            (service as any).logger = null;
 
            // Should not throw
            await expect(service.placeOrder(validOrderRequest))
                .resolves.not.toThrow();
        });
    });
});

Test All Configurations

The key insight is to test the service works correctly in EVERY valid configuration. This includes testing that optional dependencies truly are optional—the service doesn't fail when they're absent.

Summary: Optional Dependencies Pattern

We've explored how setter injection enables the Optional Dependencies Pattern—allowing classes to work with or without certain collaborators while enhancing functionality when those collaborators are available.

Key Takeaways

•Distinguish mandatory from optional — Ask: 'Can the class fulfill its core contract without this dependency?' Mandatory goes in constructor; optional goes in setters.
•Common optional categories — Logging, metrics, caching, auditing, notifications, and analytics are typically optional. Data stores and core services are typically mandatory.
•Graceful degradation strategies — Silent skip, default/fallback behavior, try-catch isolation, and null object defaults each have their place.
•Null Object Pattern synergy — Pre-initializing with null objects eliminates null checks entirely and is the cleanest approach for multiple optional dependencies.
•Configuration flexibility — Optional dependencies enable different behavior in dev/test/prod without code changes—just different wiring.
•Test all configurations — Verify the class works without optional dependencies and with various combinations.

What's Next:

Now that we understand how to work with optional dependencies, the next page examines the trade-offs of setter injection—the costs, risks, and architectural implications that inform when setter injection is appropriate and when it should be avoided.

Page Complete

You now understand the Optional Dependencies Pattern—how to design classes that gracefully degrade when optional collaborators are absent while enhancing functionality when they're present. Next, we'll examine the trade-offs that determine when this flexibility is worth the cost.