Dependency Injection Fundamentals - Learning Module

Loading content...

0/246

Choosing the Right Injection Style

From Knowledge to Judgment

You now understand the mechanics of Constructor, Setter, and Interface Injection. But knowing how each pattern works is different from knowing when to apply each one. This page bridges that gap—transforming theoretical knowledge into practical engineering judgment.

In real projects, you'll face nuanced situations: circular dependencies that seem to require setter injection, optional features that could go either way, framework constraints that limit your options, and legacy code with embedded assumptions. The ability to navigate these situations with confidence separates junior developers from seasoned engineers.

What You Will Learn

By the end of this page, you will have a systematic decision framework for choosing injection styles, understand how to evaluate trade-offs in real scenarios, recognize anti-patterns that masquerade as valid choices, and develop the judgment to make confident DI decisions in production systems.

Start with Constructor Injection (The Default)

Before any decision framework, internalize this principle:

Constructor Injection is the default choice. Use it unless you have a specific, compelling reason not to.

This isn't arbitrary preference—it's based on the fundamental properties Constructor Injection provides:

Completeness — Objects are fully initialized upon construction
Immutability — Dependencies can be readonly/final
Visibility — Requirements are explicit in the constructor signature
Simplicity — No temporal coupling, no initialization order concerns
Testability — Mocks are passed as constructor arguments

These properties align with good object-oriented design principles. When you're unsure which injection method to use, ask: "Why can't I use Constructor Injection here?" If you can't answer that question, use Constructor Injection.

The Mental Model

Think of Constructor Injection as the "secure" default. Like defaulting to immutable data structures or private visibility, it's the safe starting point. You deviate only when requirements force you to, and you document why.

default-constructor-injection.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
// THE DEFAULT: Constructor Injection for all dependencies
class OrderProcessingService {
    constructor(
        private readonly orderRepository: OrderRepository,
        private readonly paymentGateway: PaymentGateway,
        private readonly inventoryService: InventoryService,
        private readonly notificationService: NotificationService,
        private readonly auditLogger: AuditLogger
    ) {
        // All dependencies required, immutable, visible
    }
    
    // Object is ready to use immediately
    async processOrder(order: Order): Promise<ProcessingResult> {
        // No null checks, no "is initialized" checks
        // Dependencies are guaranteed present
    }
}
 
// Tests are straightforward
const service = new OrderProcessingService(
    mockRepository,
    mockPayment,
    mockInventory,
    mockNotification,
    mockAudit
);

The Decision Framework

When deciding on injection style, work through these questions in order:

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

•Yes, required → Strongly prefer Constructor Injection
•No, optional (enhances but not essential) → Consider Setter Injection
•It's complicated → Usually means "required" — use Constructor

Question 2: Can all dependencies be available at construction time?

•Yes → Use Constructor Injection
•No, circular dependency → Use Setter for ONE side, then redesign
•No, framework creates object first → Use Setter or Interface (framework dictates)

Question 3: Is this a business dependency or infrastructure/cross-cutting concern?

•Business dependency → Constructor Injection
•Cross-cutting (logging, metrics, config) → Constructor preferred, but Interface reasonable for framework-provided services
•Framework service (container, environment) → Interface Injection (*Aware pattern)

Question 4: Should the dependency be immutable after initialization?

•Yes, immutable → Constructor Injection (readonly/final fields)
•No, may change → Setter Injection (use sparingly)
•Immutable but set after construction → Setter + freeze pattern

Converting Mermaid diagram...

Scenario Analysis: Real-World Cases

Let's apply the decision framework to realistic scenarios:

Scenario A: Core Business Service

•Context: InvoiceService needs InvoiceRepository, TaxCalculator, PdfGenerator
•Analysis: All required for core function. Available at construction. Business dependencies.
•Decision: Constructor Injection for all three
•Confidence: Very high — textbook case

scenario-a.ts
TypeScript
1
2
3
4
5
6
7
8
9
// Scenario A: Core business service
class InvoiceService {
    constructor(
        private readonly repository: InvoiceRepository,
        private readonly taxCalculator: TaxCalculator,
        private readonly pdfGenerator: PdfGenerator
    ) { }
    // ✅ All required, all in constructor
}

Scenario B: Optional Performance Enhancement

•Context: ProductService always needs ProductRepository, optionally uses ProductCache
•Analysis: Repository required. Cache optional (enhances performance but not essential).
•Decision: Constructor for repository. Two options for cache:
•
- Option 1 (Preferred): Constructor with default NullCache
•
- Option 2: Setter injection for cache

scenario-b.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
// Scenario B: Optional enhancement
 
// Option 1 (Preferred): Null Object pattern
class ProductService {
    constructor(
        private readonly repository: ProductRepository,
        private readonly cache: ProductCache = new NullProductCache()
    ) { }
    // ✅ Cache defaults to no-op, code stays clean
}
 
// Option 2: Setter for optional
class ProductService {
    private cache?: ProductCache;
    
    constructor(
        private readonly repository: ProductRepository
    ) { }
    
    setCache(cache: ProductCache): void {
        this.cache = cache;
    }
    // ⚠️ Must check cache before use
}

Scenario C: Circular Dependency

•Context: OrderService needs CustomerService, CustomerService needs OrderService
•Analysis: Circular — can't use pure constructor injection. Design smell detected.
•Decision: Break cycle with setter for ONE direction. Plan refactoring.
•Long-term: Extract shared concern into third class, or introduce mediator

scenario-c.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
// Scenario C: Circular dependency (temporary solution)
 
class OrderService {
    private customerService?: CustomerService;
    
    constructor(
        private readonly repository: OrderRepository
    ) { }
    
    // Setter breaks the cycle
    setCustomerService(service: CustomerService): void {
        this.customerService = service;
    }
}
 
class CustomerService {
    constructor(
        private readonly repository: CustomerRepository,
        private readonly orderService: OrderService  // Constructor here
    ) { }
}
 
// Wiring
const orderService = new OrderService(orderRepo);
const customerService = new CustomerService(customerRepo, orderService);
orderService.setCustomerService(customerService);
 
// ⚠️ TODO: Refactor to eliminate circular dependency

Scenario D: Framework-Provided Services

•Context: Spring bean needs ApplicationContext, Environment
•Analysis: Framework services. Class doesn't control instantiation.
•Decision: Interface Injection via *Aware interfaces
•Rationale: Standard pattern for framework integration

scenario-d.java
Java
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
// Scenario D: Framework-provided services
@Service
public class DynamicBeanLoader implements 
        ApplicationContextAware, 
        EnvironmentAware {
    
    private ApplicationContext context;
    private Environment environment;
    
    // Constructor for business dependencies
    public DynamicBeanLoader(ConfigRepository configRepo) {
        this.configRepo = configRepo;
    }
    
    // Interface injection for framework services
    @Override
    public void setApplicationContext(ApplicationContext context) {
        this.context = context;
    }
    
    @Override  
    public void setEnvironment(Environment environment) {
        this.environment = environment;
    }
    // ✅ Hybrid: Constructor for business, Interface for framework
}

Scenario E: Reconfigurable Strategy

•Context: PaymentProcessor can switch between payment gateways at runtime
•Analysis: Strategy genuinely changes during object lifetime. Rare but valid.
•Decision: Setter for the swappable strategy
•Caution: Ensure thread-safety if accessed concurrently

scenario-e.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Scenario E: Reconfigurable strategy
class PaymentProcessor {
    private gateway: PaymentGateway;
    
    constructor(
        private readonly repository: PaymentRepository,
        initialGateway: PaymentGateway  // Initial via constructor
    ) {
        this.gateway = initialGateway;
    }
    
    // Setter for runtime reconfiguration
    setGateway(gateway: PaymentGateway): void {
        if (!gateway) {
            throw new Error("PaymentGateway cannot be null");
        }
        this.gateway = gateway;
        this.logGatewayChange(gateway);
    }
    
    // ⚠️ Consider thread-safety in concurrent environments
}

Anti-Patterns to Avoid

Some injection choices are disguised anti-patterns. Recognize and avoid these:

Anti-Pattern 1: Setter Injection to Hide Constructor Explosion

•Symptom: Class has 10+ dependencies, switched to setter injection "because constructor was too long"
•Reality: The class violates Single Responsibility Principle
•The fix: Decompose the class into focused, smaller classes
•Why it's bad: Hides design problem, introduces incomplete initialization risk

Anti-Pattern 2: Setter Injection for 'Flexibility'

•Symptom: "We use setter injection everywhere for flexibility"
•Reality: Flexibility you'll never use at the cost of guaranteed correctness
•The fix: Use constructor injection by default; setters only for genuinely optional deps
•Why it's bad: Objects can be used in incomplete states; dependencies are mutable

Anti-Pattern 3: Field Injection for Convenience

•Symptom: Using @Autowired on private fields directly (no constructor or setter)
•Reality: Requires reflection for testing; hides dependencies completely
•The fix: Use constructor injection, even if it means more code
•Why it's bad: Can't instantiate class without DI framework; testing requires reflection

anti-patterns.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
// ❌ ANTI-PATTERN: Field injection (common in Spring without constructor)
@Service
public class OrderService {
    @Autowired
    private OrderRepository repository;  // No constructor!
    
    @Autowired
    private PaymentGateway gateway;  // Hidden dependency
    
    // How do you test this without Spring?
    // You need reflection to inject mocks.
}
 
// ✅ CORRECT: Constructor injection
@Service
public class OrderService {
    private final OrderRepository repository;
    private final PaymentGateway gateway;
    
    @Autowired  // Or omit - Spring autowires single constructor
    public OrderService(OrderRepository repository, PaymentGateway gateway) {
        this.repository = repository;
        this.gateway = gateway;
    }
    
    // Testing: just call constructor with mocks
}

Anti-Pattern 4: Service Locator as 'Injection'

•Symptom: Class receives a container/locator and queries for dependencies
•Reality: This is NOT dependency injection — it's Service Locator pattern
•The fix: Inject the specific dependencies, not the container
•Why it's bad: Hides dependencies; class couples to container interface

service-locator-anti-pattern.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
// ❌ ANTI-PATTERN: Service Locator (NOT dependency injection)
class OrderService {
    constructor(private container: Container) { }
    
    async processOrder(order: Order): Promise<void> {
        // Pulls dependencies from container - hides requirements!
        const repo = this.container.get<OrderRepository>("OrderRepository");
        const gateway = this.container.get<PaymentGateway>("PaymentGateway");
        
        await gateway.charge(order);
        await repo.save(order);
    }
}
 
// ✅ CORRECT: Inject actual dependencies
class OrderService {
    constructor(
        private readonly repository: OrderRepository,
        private readonly gateway: PaymentGateway
    ) { }
    
    async processOrder(order: Order): Promise<void> {
        await this.gateway.charge(order);
        await this.repository.save(order);
    }
    // Dependencies are VISIBLE, not hidden in container queries
}

Recognize the Escape

When you find yourself reaching for setter injection or service locator, pause and ask: "Am I solving a real problem, or escaping from a design issue?" Constructor explosion, circular dependencies, and 'flexibility needs' are often symptoms of design problems, not reasons to abandon Constructor Injection.

Hybrid and Mixed Injection Strategies

Real-world classes often use multiple injection styles appropriately. The key is using each style for its intended purpose:

hybrid-injection.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
// HYBRID INJECTION STRATEGY
 
interface LoggerAware {
    setLogger(logger: Logger): void;
}
 
class EnterpriseOrderService implements LoggerAware {
    // 1. CONSTRUCTOR: Required business dependencies
    private readonly repository: OrderRepository;
    private readonly paymentGateway: PaymentGateway;
    private readonly inventoryService: InventoryService;
    
    // 2. SETTER: Optional enhancements
    private cache?: OrderCache;
    private metrics?: MetricsCollector;
    
    // 3. INTERFACE: Framework/cross-cutting services
    private logger!: Logger;
    
    constructor(
        repository: OrderRepository,
        paymentGateway: PaymentGateway,
        inventoryService: InventoryService
    ) {
        // Validate required dependencies
        if (!repository) throw new Error("OrderRepository required");
        if (!paymentGateway) throw new Error("PaymentGateway required");
        if (!inventoryService) throw new Error("InventoryService required");
        
        this.repository = repository;
        this.paymentGateway = paymentGateway;
        this.inventoryService = inventoryService;
    }
    
    // Optional setter injection
    setCache(cache: OrderCache): void {
        this.cache = cache;
    }
    
    setMetrics(metrics: MetricsCollector): void {
        this.metrics = metrics;
    }
    
    // Interface injection (LoggerAware)
    setLogger(logger: Logger): void {
        this.logger = logger;
    }
    
    async processOrder(order: Order): Promise<ProcessingResult> {
        const startTime = Date.now();
        
        // Use logger (must be injected)
        this.logger.info(`Processing order ${order.id}`);
        
        // Business logic uses constructor-injected deps
        await this.inventoryService.reserve(order.items);
        await this.paymentGateway.charge(order);
        await this.repository.save(order);
        
        // Use optional cache if available
        if (this.cache) {
            await this.cache.invalidate(order.customerId);
        }
        
        // Use optional metrics if available  
        this.metrics?.recordTiming("order.process", Date.now() - startTime);
        
        return ProcessingResult.success(order);
    }
}

When to Use Each Style in Hybrid Approach
Dependency Type	Injection Style	Example
Core business dependencies	Constructor	Repository, PaymentGateway
Optional enhancements	Setter	Cache, Metrics, Audit
Framework services	Interface (*Aware)	Logger, Config, Context
Configuration objects	Constructor	ServiceConfig, Options
Swappable strategies	Constructor (or Setter if truly dynamic)	PricingStrategy

Framework-Specific Recommendations

Different frameworks have different conventions. Here are best practices for major frameworks:

Spring Framework (Java)

•Primary: Constructor Injection (Spring auto-detects single constructor)
•Optional deps: @Autowired(required = false) on setter OR constructor with default
•Framework services: Implement *Aware interfaces (ApplicationContextAware, etc.)
•Avoid: Field injection (@Autowired on private fields)

NestJS (TypeScript)

•Primary: Constructor Injection with @Injectable()
•Optional deps: @Optional() decorator in constructor parameter
•Provider configuration: Custom providers in module definition
•Avoid: Property injection without clear indication in constructor

Angular (TypeScript)

•Primary: Constructor Injection
•Optional deps: @Optional() decorator
•Self/SkipSelf: Control injector hierarchy traversal
•Inputs: Use @Input() setters for component inputs (different from DI)

.NET Core DI (C#)

•Primary: Constructor Injection
•Multiple constructors: DI picks the one with most resolvable parameters
•Options pattern: Use IOptions<T> for configuration
•Optional deps: Check for null or provide defaults

Manual/No Framework (Any Language)

•Primary: Constructor Injection in composition root
•Optional deps: Constructor with defaults or builder pattern
•Testing: Pass mocks directly to constructor
•Consider: Poor man's DI is fine for smaller projects

Quick Decision Checklist

Use this checklist when deciding on injection style for a dependency:

Constructor Injection Checklist

•✓ Dependency is required for the class to function
•✓ Dependency is available at construction time
•✓ Dependency should not change after initialization
•✓ It's a business/domain dependency
•✓ You want explicit, visible requirements
•→ Use Constructor Injection

Setter Injection Checklist

•✓ Dependency is truly optional (class works without it)
•✓ Null Object pattern doesn't fit the use case
•✓ OR: Breaking circular dependency (temporary)
•✓ OR: Framework requires default constructor
•✓ You'll add defensive validation for initialization
•→ Use Setter Injection

Interface Injection Checklist

•✓ Dependency is a framework-provided service
•✓ Standard interface exists (*Aware, *Listener, etc.)
•✓ Multiple classes need same injection mechanism
•✓ You're integrating with a framework's lifecycle
•→ Use Interface Injection

When in Doubt

When none of the checklists clearly apply, default to Constructor Injection. You can always refactor to setter or interface injection later if requirements emerge. Going the other direction (setter to constructor) is harder because it changes the construction contract.

Summary: Choosing with Confidence

You now have the knowledge and framework to make confident injection style decisions. Let's consolidate:

Key Takeaways

•Default to Constructor Injection — It's the safe, complete, testable default. Deviate only with explicit reason.
•Decision framework — Is it required? Available at construction? Business or infrastructure? Should it be immutable?
•Setter for optional — Truly optional dependencies that enhance but aren't essential. Prefer Null Object pattern when possible.
•Interface for frameworks — Framework-provided services using standardized *Aware patterns.
•Avoid anti-patterns — Constructor explosion hiding, field injection, service locator disguised as DI.
•Hybrid is legitimate — Real systems often use multiple styles appropriately. Each for its intended purpose.
•Framework conventions — Follow your framework's recommendations while understanding the underlying principles.

Module Complete:

You've now completed the Dependency Injection Fundamentals module. You understand:

What DI is and how it relates to DIP
Constructor Injection mechanics and best practices
Setter Injection patterns and defensive techniques
Interface Injection for framework integration
Decision frameworks for choosing the right approach

The next module explores Inversion of Control Containers—frameworks that automate dependency resolution and lifecycle management, taking DI from manual wiring to industrial-scale configuration.

Engineering Judgment Developed

You now have the theoretical knowledge and practical judgment to make informed DI decisions. Remember: good engineering isn't about blindly following rules—it's about understanding trade-offs and making conscious choices. When you choose an injection style, you should be able to explain why it's the right choice for that situation.