System Design (HLD)Dependency Injection Fundamentals

Dependency Injection Fundamentals

LevelIntermediate

Duration60 mins

TopicDependency Injection Fundamentals

3 / 5

Setter Injection

When Constructor Injection Falls Short

Constructor Injection is the preferred approach for dependency injection, but it's not universally applicable. Certain scenarios—framework constraints, circular dependencies, optional dependencies, and post-construction configuration—require an alternative. Setter Injection (also called Property Injection) provides that alternative.

With Setter Injection, dependencies are provided through setter methods or directly assignable properties after the object is constructed. The object is created first, then dependencies are "set" into it through dedicated methods.

This flexibility comes at a cost: reduced immutability, temporal coupling, and risk of incomplete initialization. Understanding these trade-offs is essential for using Setter Injection appropriately.

What You Will Learn

By the end of this page, you will understand Setter Injection mechanics, recognize legitimate use cases, implement defensive patterns to mitigate risks, handle initialization validation, and make informed decisions about when setter injection is appropriate versus when to choose alternatives.

Setter Injection Mechanics

Setter Injection follows a distinct pattern:

Object is constructed — May use default constructor or constructor with some dependencies.
Setter methods are called — Injector calls setter methods to provide dependencies one at a time.
Object becomes ready — Only after all setters are called is the object fully initialized.
Methods are invoked — Now the object can perform its function.

Unlike Constructor Injection where the object is ready immediately upon construction, Setter Injection introduces a two-phase initialization: construction, then configuration.

setter-injection-anatomy.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
42
43
44
45
46
47
// ANATOMY OF SETTER INJECTION
 
class OrderProcessingService {
    // Dependencies declared without initialization
    private orderRepository?: OrderRepository;
    private paymentGateway?: PaymentGateway;
    private eventPublisher?: EventPublisher;
    
    // Default constructor - object exists but is incomplete
    constructor() {
        // No dependencies provided at construction time
    }
    
    // Setter for each dependency
    setOrderRepository(repository: OrderRepository): void {
        this.orderRepository = repository;
    }
    
    setPaymentGateway(gateway: PaymentGateway): void {
        this.paymentGateway = gateway;
    }
    
    setEventPublisher(publisher: EventPublisher): void {
        this.eventPublisher = publisher;
    }
    
    // Business method - requires all dependencies
    async processOrder(order: Order): Promise<ProcessingResult> {
        // Must check if dependencies are present
        if (!this.orderRepository || !this.paymentGateway || !this.eventPublisher) {
            throw new Error("Service not fully initialized - missing dependencies");
        }
        
        const result = await this.paymentGateway.charge(order.paymentDetails);
        await this.orderRepository.save(order);
        await this.eventPublisher.publish(new OrderProcessedEvent(order.id));
        
        return ProcessingResult.success(order);
    }
}
 
// Usage by injector
const service = new OrderProcessingService();  // Object exists but is incomplete
service.setOrderRepository(new PostgresOrderRepository());
service.setPaymentGateway(new StripePaymentGateway());
service.setEventPublisher(new KafkaEventPublisher());
// NOW the object is ready to use

The Incomplete Object Problem

Notice how the object exists in an incomplete state between construction and setter calls. This is the fundamental concern with Setter Injection—the object can be used before it's ready, leading to NullPointerExceptions or unclear error messages deep in the call stack.

Legitimate Use Cases for Setter Injection

Despite its drawbacks, Setter Injection has legitimate use cases where it's the right choice or even the only option:

1. Optional Dependencies

•Dependencies that enhance functionality but aren't required
•The class can function without them, perhaps with reduced capabilities
•Example: cache layer, analytics tracker, optional logging

optional-setter.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
class OrderService {
    private repository: OrderRepository;  // Required - in constructor
    private cache?: OrderCache;           // Optional - via setter
    private analytics?: AnalyticsTracker; // Optional - via setter
    
    constructor(repository: OrderRepository) {
        this.repository = repository;  // Required dependency
    }
    
    // Optional setters for enhanced functionality
    setCache(cache: OrderCache): void {
        this.cache = cache;
    }
    
    setAnalytics(analytics: AnalyticsTracker): void {
        this.analytics = analytics;
    }
    
    async getOrder(id: string): Promise<Order | null> {
        // Use cache if available, otherwise skip caching
        if (this.cache) {
            const cached = await this.cache.get(id);
            if (cached) return cached;
        }
        
        const order = await this.repository.findById(id);
        
        if (order && this.cache) {
            await this.cache.set(id, order);
        }
        
        // Track if analytics available
        this.analytics?.track("order_viewed", { id });
        
        return order;
    }
}

2. Breaking Circular Dependencies

•When A depends on B and B depends on A
•Constructor injection fails—both need the other during construction
•One dependency can be set via setter after both are constructed

circular-dependency.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
// Circular dependency: A needs B, B needs A
// Constructor injection alone cannot handle this
 
class ServiceA {
    private serviceB?: ServiceB;
    
    // B is set after construction to break the cycle
    setServiceB(serviceB: ServiceB): void {
        this.serviceB = serviceB;
    }
    
    doSomething(): void {
        // Use B after it's been set
        this.serviceB?.collaborate();
    }
}
 
class ServiceB {
    // A is injected through constructor
    constructor(private serviceA: ServiceA) { }
    
    collaborate(): void {
        // B can use A
    }
}
 
// Composition root breaks the cycle
const serviceA = new ServiceA();      // Create A first
const serviceB = new ServiceB(serviceA);  // Create B with A
serviceA.setServiceB(serviceB);       // Now set B on A

Circular Dependencies Are Design Smells

While Setter Injection can break circular dependencies, the circular dependency itself often indicates a design problem. Consider if the classes should be merged, if an interface should be extracted, or if a mediator pattern would be cleaner. Setter injection is a workaround, not a cure.

3. Framework Constraints

•Some frameworks require a default constructor
•Legacy frameworks that instantiate objects reflectively
•Serialization/deserialization scenarios
•ORM entities that need a no-arg constructor

framework-constraint.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
// Example: MVC Controller with framework instantiation
// Framework creates controllers with no-arg constructor
 
class OrderController {
    private orderService!: OrderService;
    private authService!: AuthService;
    
    // Framework requires default constructor
    constructor() { }
    
    // Framework calls setters to inject dependencies
    @Inject()
    setOrderService(service: OrderService): void {
        this.orderService = service;
    }
    
    @Inject()
    setAuthService(service: AuthService): void {
        this.authService = service;
    }
    
    @Get("/orders/:id")
    async getOrder(req: Request, res: Response): Promise<void> {
        // By the time this is called, setters have been invoked
        const user = await this.authService.authenticate(req);
        const order = await this.orderService.getOrder(req.params.id);
        res.json(order);
    }
}

4. Reconfigurable Dependencies

•Dependencies that legitimately change during object lifetime
•Strategy pattern with swappable strategies
•Hot-reloadable configuration
•Rare in well-designed systems

Risks and Pitfalls of Setter Injection

Setter Injection introduces significant risks that must be understood and mitigated:

Key Risks

•Incomplete Initialization — Object exists before dependencies are set. Methods called on incomplete objects throw null errors or behave incorrectly.
•Temporal Coupling — Setters must be called in a certain order or before certain methods. This invisible requirement is easy to violate.
•Mutability — Dependencies can be changed after initialization, introducing state changes that are difficult to reason about.
•Hidden Requirements — Unlike constructor parameters, setter-injected dependencies are not visible in the type signature. Callers must know to call setters.
•Thread Safety — Mutable dependencies require synchronization in concurrent environments. Forgetting this causes race conditions.
•Testing Complexity — Tests must call setters in the right order. Forgetting a setter causes cryptic test failures.

risk-incomplete.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// ❌ Risk: Incomplete Initialization
class OrderService {
    private repository?: OrderRepository;
    
    setRepository(repo: OrderRepository) {
        this.repository = repo;
    }
    
    async getOrder(id: string) {
        // If setRepository wasn't called:
        // TypeError: Cannot read 'findById' of undefined
        return this.repository!.findById(id);
    }
}
 
// Mistake: forgot to call setter
const service = new OrderService();
// service.setRepository(...); // Oops!
await service.getOrder("123"); // 💥 Crashes

risk-mutability.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
// ❌ Risk: Mutability and State Changes
class PaymentProcessor {
    private gateway?: PaymentGateway;
    
    setGateway(gw: PaymentGateway) {
        this.gateway = gw;
    }
    
    async process(payment: Payment) {
        return this.gateway!.charge(payment);
    }
}
 
const processor = new PaymentProcessor();
processor.setGateway(new StripeGateway());
 
// Order 1 goes to Stripe
await processor.process(order1);
 
// Mid-execution, someone changes gateway!
processor.setGateway(new PayPalGateway());
 
// Order 2 goes to PayPal unexpectedly
await processor.process(order2); // 🤔

risk-temporal-coupling.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
// ❌ Risk: Temporal Coupling - order matters
 
class ReportGenerator {
    private dataSource?: DataSource;
    private formatter?: Formatter;
    private validator?: Validator;
    
    setDataSource(ds: DataSource) {
        this.dataSource = ds;
    }
    
    setFormatter(fmt: Formatter) {
        // Formatter might depend on dataSource being set first
        if (!this.dataSource) {
            throw new Error("DataSource must be set before Formatter");
        }
        this.formatter = fmt;
    }
    
    setValidator(val: Validator) {
        // Validator might need formatter
        if (!this.formatter) {
            throw new Error("Formatter must be set before Validator");
        }
        this.validator = val;
    }
}
 
// Must call setters in exact order - invisible requirement!
const gen = new ReportGenerator();
gen.setDataSource(new SqlDataSource());
gen.setFormatter(new PdfFormatter());  // Must come after dataSource
gen.setValidator(new StrictValidator()); // Must come after formatter

The Visibility Problem

With Constructor Injection, the constructor signature reveals all requirements. With Setter Injection, requirements are scattered across multiple setters. A developer using the class must know to call specific setters—knowledge that's not enforced by the type system.

Defensive Patterns for Safer Setter Injection

When Setter Injection is necessary, apply defensive patterns to mitigate its risks:

Pattern 1: Initialization Validation

•Check that all required dependencies are set before any business method runs
•Throw descriptive errors listing missing dependencies
•Consider an explicit 'initialize()' or 'validate()' method

defensive-validation.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
class OrderService {
    private repository?: OrderRepository;
    private paymentGateway?: PaymentGateway;
    private notifier?: OrderNotifier;
    
    setRepository(repo: OrderRepository): void {
        this.repository = repo;
    }
    
    setPaymentGateway(gateway: PaymentGateway): void {
        this.paymentGateway = gateway;
    }
    
    setNotifier(notifier: OrderNotifier): void {
        this.notifier = notifier;
    }
    
    // Explicit initialization check
    private ensureInitialized(): void {
        const missing: string[] = [];
        
        if (!this.repository) missing.push("OrderRepository");
        if (!this.paymentGateway) missing.push("PaymentGateway");
        if (!this.notifier) missing.push("OrderNotifier");
        
        if (missing.length > 0) {
            throw new Error(
                `OrderService not fully initialized. Missing: ${missing.join(", ")}. ` +
                `Call setRepository(), setPaymentGateway(), setNotifier() first.`
            );
        }
    }
    
    // Business methods call ensureInitialized
    async processOrder(order: Order): Promise<void> {
        this.ensureInitialized();
        
        // Now safe to use - TypeScript knows they're defined
        await this.paymentGateway!.charge(order);
        await this.repository!.save(order);
        await this.notifier!.notify(order);
    }
}

Pattern 2: Builder with Setter Injection

•Use a builder that enforces all dependencies are set
•Builder.build() validates completeness
•Object is only created when fully configured

builder-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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
class OrderServiceBuilder {
    private repository?: OrderRepository;
    private paymentGateway?: PaymentGateway;
    private notifier?: OrderNotifier;
    
    withRepository(repo: OrderRepository): this {
        this.repository = repo;
        return this;
    }
    
    withPaymentGateway(gateway: PaymentGateway): this {
        this.paymentGateway = gateway;
        return this;
    }
    
    withNotifier(notifier: OrderNotifier): this {
        this.notifier = notifier;
        return this;
    }
    
    build(): OrderService {
        // Validate all required dependencies before creating
        if (!this.repository) {
            throw new Error("OrderRepository is required");
        }
        if (!this.paymentGateway) {
            throw new Error("PaymentGateway is required");
        }
        if (!this.notifier) {
            throw new Error("OrderNotifier is required");
        }
        
        // Create with validated dependencies
        const service = new OrderService();
        service.setRepository(this.repository);
        service.setPaymentGateway(this.paymentGateway);
        service.setNotifier(this.notifier);
        
        return service;
    }
}
 
// Usage - build() ensures complete configuration
const service = new OrderServiceBuilder()
    .withRepository(new PostgresOrderRepository())
    .withPaymentGateway(new StripeGateway())
    .withNotifier(new EmailNotifier())
    .build();  // Throws if anything missing

Pattern 3: Immutable After Initialization

•Allow setters only until an 'initialize()' method is called
•After initialization, setters throw exceptions
•Reduces mutability risk while allowing setter-based configuration

immutable-after-init.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
class OrderService {
    private repository?: OrderRepository;
    private paymentGateway?: PaymentGateway;
    private initialized = false;
    
    setRepository(repo: OrderRepository): void {
        if (this.initialized) {
            throw new Error("Cannot modify dependencies after initialization");
        }
        this.repository = repo;
    }
    
    setPaymentGateway(gateway: PaymentGateway): void {
        if (this.initialized) {
            throw new Error("Cannot modify dependencies after initialization");
        }
        this.paymentGateway = gateway;
    }
    
    initialize(): void {
        if (this.initialized) {
            throw new Error("Already initialized");
        }
        
        if (!this.repository || !this.paymentGateway) {
            throw new Error("Cannot initialize: missing dependencies");
        }
        
        this.initialized = true;
        // Object is now immutable - setters will throw
    }
    
    async processOrder(order: Order): Promise<void> {
        if (!this.initialized) {
            throw new Error("Must call initialize() before using");
        }
        
        await this.paymentGateway!.charge(order);
        await this.repository!.save(order);
    }
}
 
// Usage
const service = new OrderService();
service.setRepository(new PostgresOrderRepository());
service.setPaymentGateway(new StripeGateway());
service.initialize();  // Locks configuration
 
// Now setters are blocked
service.setRepository(new OtherRepo()); // 💥 Throws!

Type-Safe Builders

In TypeScript, you can use type-state patterns to make the builder's state visible at compile time—the build() method only exists after all required setters are called. This provides compile-time safety for setter-injected dependencies.

Combining Constructor and Setter Injection

The most robust pattern combines both injection styles:

Required dependencies → Constructor Injection
Optional dependencies → Setter Injection

This hybrid approach gets the best of both worlds: guaranteed completeness for essentials, flexibility for enhancements.

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
71
72
73
74
75
76
// HYBRID PATTERN: Required via constructor, optional via setter
 
class OrderProcessingService {
    // Required dependencies - final after construction
    private readonly repository: OrderRepository;
    private readonly paymentGateway: PaymentGateway;
    
    // Optional dependencies - can be set later
    private cache?: OrderCache;
    private analytics?: AnalyticsTracker;
    private auditLogger?: AuditLogger;
    
    // Constructor takes required dependencies only
    constructor(
        repository: OrderRepository,
        paymentGateway: PaymentGateway
    ) {
        if (!repository) throw new Error("OrderRepository is required");
        if (!paymentGateway) throw new Error("PaymentGateway is required");
        
        this.repository = repository;
        this.paymentGateway = paymentGateway;
    }
    
    // Setters for optional dependencies
    setCache(cache: OrderCache): void {
        this.cache = cache;
    }
    
    setAnalytics(analytics: AnalyticsTracker): void {
        this.analytics = analytics;
    }
    
    setAuditLogger(logger: AuditLogger): void {
        this.auditLogger = logger;
    }
    
    async processOrder(order: Order): Promise<ProcessingResult> {
        // Required dependencies are guaranteed - no null checks
        const paymentResult = await this.paymentGateway.charge(order);
        
        // Optional: check & invalidate cache
        if (this.cache) {
            await this.cache.invalidate(order.customerId);
        }
        
        // Required: save order
        await this.repository.save(order);
        
        // Optional: analytics tracking
        this.analytics?.track("order_processed", {
            orderId: order.id,
            amount: order.total
        });
        
        // Optional: audit logging
        this.auditLogger?.log({
            action: "ORDER_PROCESSED",
            entityId: order.id,
            timestamp: new Date()
        });
        
        return ProcessingResult.success(order);
    }
}
 
// Usage - required in constructor, optional via setters
const service = new OrderProcessingService(
    new PostgresOrderRepository(),
    new StripePaymentGateway()
);
 
// Optionally add enhanced capabilities
service.setCache(new RedisOrderCache());
service.setAnalytics(new MixpanelTracker());
// auditLogger left unset - service works without it

When to Use Which Injection Type
Scenario	Injection Type	Rationale
Core dependencies without which class cannot function	Constructor	Guarantees completeness, immutable
Enhancement dependencies that add features	Setter	Flexibility, optional by nature
Configuration values	Constructor (as config object)	Required for operation
Swappable strategies	Constructor or Setter	Depends on whether initial strategy is required
Circular dependency workaround	Setter (for one direction)	Necessary evil, consider redesign

The Principle

Use Constructor Injection by default for all dependencies. Only use Setter Injection when there's a specific reason: the dependency is optional, framework constraints require it, or you're breaking a circular dependency (which you should consider redesigning).

Framework Support for Setter Injection

Major DI frameworks support Setter Injection, though most recommend Constructor Injection as the primary mechanism.

Spring Framework (Java):

spring-setter-injection.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
27
28
29
30
31
32
33
@Service
public class OrderService {
    private OrderRepository repository;
    private AnalyticsTracker analytics;  // Optional
    
    // Constructor injection for required dependency
    @Autowired
    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }
    
    // Setter injection for optional dependency
    // required=false makes it optional
    @Autowired(required = false)
    public void setAnalytics(AnalyticsTracker analytics) {
        this.analytics = analytics;
    }
}
 
// Or using @Inject (JSR-330 standard)
@Service
public class OrderService {
    @Inject
    private OrderRepository repository;  // Field injection
    
    private AnalyticsTracker analytics;
    
    @Inject
    @Optional  // Makes it optional
    public void setAnalytics(AnalyticsTracker analytics) {
        this.analytics = analytics;
    }
}

NestJS (TypeScript):

nestjs-setter-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
@Injectable()
export class OrderService {
    // Constructor injection for required
    constructor(
        private readonly repository: OrderRepository
    ) { }
    
    // Property injection with @Inject decorator
    @Inject()
    @Optional()  // Makes it optional
    private analytics?: AnalyticsTracker;
}
 
// Alternative: Method injection (less common in NestJS)
@Injectable()
export class OrderService {
    private analytics?: AnalyticsTracker;
    
    constructor(
        private readonly repository: OrderRepository
    ) { }
    
    @Inject()
    setAnalytics(@Optional() analytics?: AnalyticsTracker): void {
        this.analytics = analytics;
    }
}

Angular (TypeScript):

angular-setter-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
@Component({
    selector: 'app-order',
    template: '...'
})
export class OrderComponent {
    // Angular primarily uses constructor injection
    constructor(
        private orderService: OrderService
    ) { }
    
    // Optional injection using @Optional decorator
    constructor(
        private orderService: OrderService,
        @Optional() private analytics?: AnalyticsService
    ) { }
    
    // Setter-style with @Input for component inputs
    @Input()
    set config(value: OrderConfig) {
        this.orderConfig = value;
        this.initialize();
    }
}

Field Injection Warning

Many frameworks support 'field injection' (annotating private fields directly). While convenient, this makes testing harder—you need reflection to inject mocks. Prefer constructor or setter injection where the setters are explicit methods.

Testing Classes with Setter Injection

Testing setter-injected classes requires more care than constructor-injected classes. Each test must ensure proper setup:

testing-setter-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
describe("OrderService with setter injection", () => {
    let service: OrderService;
    let mockRepository: jest.Mocked<OrderRepository>;
    let mockGateway: jest.Mocked<PaymentGateway>;
    let mockCache: jest.Mocked<OrderCache>;
    
    beforeEach(() => {
        // Create service with required constructor dependencies
        mockRepository = createMockRepository();
        mockGateway = createMockGateway();
        
        service = new OrderService(mockRepository, mockGateway);
        
        // Optionally set optional dependencies for specific tests
        mockCache = createMockCache();
    });
    
    describe("with all dependencies", () => {
        beforeEach(() => {
            // Set optional dependencies
            service.setCache(mockCache);
        });
        
        it("should use cache when available", async () => {
            mockCache.get.mockResolvedValue(cachedOrder);
            
            const result = await service.getOrder("123");
            
            expect(result).toBe(cachedOrder);
            expect(mockRepository.findById).not.toHaveBeenCalled();
        });
    });
    
    describe("without optional dependencies", () => {
        // Cache not set
        
        it("should work without cache", async () => {
            mockRepository.findById.mockResolvedValue(dbOrder);
            
            const result = await service.getOrder("123");
            
            expect(result).toBe(dbOrder);
            expect(mockRepository.findById).toHaveBeenCalled();
        });
    });
    
    describe("initialization validation", () => {
        it("should throw if required setter not called", async () => {
            // Create service without calling setters for required deps
            const incompleteService = new PartialSetterService();
            // Service uses setter injection for a required dependency
            // Forgot to call setRepository()
            
            await expect(incompleteService.getOrder("123"))
                .rejects.toThrow("Service not initialized");
        });
    });
});
 
// Helper to create properly initialized service for tests
function createFullyInitializedService(): OrderService {
    const service = new OrderService();
    service.setRepository(createMockRepository());
    service.setPaymentGateway(createMockGateway());
    service.setNotifier(createMockNotifier());
    service.initialize();  // If using initialize pattern
    return service;
}

Test Setup Helpers

Create helper functions that build fully-configured service instances for tests. This centralizes the setup logic and ensures tests don't accidentally run with incomplete configuration. If the required setters change, update the helper, not every test.

Summary: Setter Injection Mastery

Setter Injection is a valuable tool when used appropriately. Let's consolidate the essential knowledge:

Key Takeaways

•Mechanics — Dependencies are set via setter methods after object construction. Object exists in incomplete state until setters are called.
•Legitimate uses — Optional dependencies, circular dependency workarounds, framework constraints, reconfigurable strategies.
•Risks — Incomplete initialization, temporal coupling, mutability, hidden requirements, thread-safety concerns.
•Defensive patterns — Initialization validation, builder pattern, immutable-after-init to mitigate risks.
•Hybrid approach — Constructor for required dependencies, setter for optional. Best of both worlds.
•Framework support — All major frameworks support setter injection, often with @Autowired, @Inject, or @Optional annotations.
•Testing — Requires careful setup to ensure all setters are called. Use helper functions to build complete instances.

What's next:

The next page explores Interface Injection—a less common but important pattern where the dependent class implements an interface that defines the injection method. We'll also cover when Interface Injection is appropriate and how it compares to other injection types.

Use Setter Injection Deliberately

Setter Injection should be a conscious choice, not a default. When you use it, apply defensive patterns to mitigate risks. The hybrid pattern—constructor for required, setter for optional—provides most of the benefits with minimal drawbacks.

3 / 5

Loading learning content...

System Design (HLD)Dependency Injection Fundamentals

Dependency Injection Fundamentals

LevelIntermediate

Duration60 mins

TopicDependency Injection Fundamentals

3 / 5

Setter Injection

When Constructor Injection Falls Short

This flexibility comes at a cost: reduced immutability, temporal coupling, and risk of incomplete initialization. Understanding these trade-offs is essential for using Setter Injection appropriately.

What You Will Learn

Setter Injection Mechanics

Setter Injection follows a distinct pattern:

Object is constructed — May use default constructor or constructor with some dependencies.
Setter methods are called — Injector calls setter methods to provide dependencies one at a time.
Object becomes ready — Only after all setters are called is the object fully initialized.
Methods are invoked — Now the object can perform its function.

Unlike Constructor Injection where the object is ready immediately upon construction, Setter Injection introduces a two-phase initialization: construction, then configuration.

setter-injection-anatomy.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
42
43
44
45
46
47
// ANATOMY OF SETTER INJECTION
 
class OrderProcessingService {
    // Dependencies declared without initialization
    private orderRepository?: OrderRepository;
    private paymentGateway?: PaymentGateway;
    private eventPublisher?: EventPublisher;
    
    // Default constructor - object exists but is incomplete
    constructor() {
        // No dependencies provided at construction time
    }
    
    // Setter for each dependency
    setOrderRepository(repository: OrderRepository): void {
        this.orderRepository = repository;
    }
    
    setPaymentGateway(gateway: PaymentGateway): void {
        this.paymentGateway = gateway;
    }
    
    setEventPublisher(publisher: EventPublisher): void {
        this.eventPublisher = publisher;
    }
    
    // Business method - requires all dependencies
    async processOrder(order: Order): Promise<ProcessingResult> {
        // Must check if dependencies are present
        if (!this.orderRepository || !this.paymentGateway || !this.eventPublisher) {
            throw new Error("Service not fully initialized - missing dependencies");
        }
        
        const result = await this.paymentGateway.charge(order.paymentDetails);
        await this.orderRepository.save(order);
        await this.eventPublisher.publish(new OrderProcessedEvent(order.id));
        
        return ProcessingResult.success(order);
    }
}
 
// Usage by injector
const service = new OrderProcessingService();  // Object exists but is incomplete
service.setOrderRepository(new PostgresOrderRepository());
service.setPaymentGateway(new StripePaymentGateway());
service.setEventPublisher(new KafkaEventPublisher());
// NOW the object is ready to use

The Incomplete Object Problem

Legitimate Use Cases for Setter Injection

Despite its drawbacks, Setter Injection has legitimate use cases where it's the right choice or even the only option:

1. Optional Dependencies

•Dependencies that enhance functionality but aren't required
•The class can function without them, perhaps with reduced capabilities
•Example: cache layer, analytics tracker, optional logging

optional-setter.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
class OrderService {
    private repository: OrderRepository;  // Required - in constructor
    private cache?: OrderCache;           // Optional - via setter
    private analytics?: AnalyticsTracker; // Optional - via setter
    
    constructor(repository: OrderRepository) {
        this.repository = repository;  // Required dependency
    }
    
    // Optional setters for enhanced functionality
    setCache(cache: OrderCache): void {
        this.cache = cache;
    }
    
    setAnalytics(analytics: AnalyticsTracker): void {
        this.analytics = analytics;
    }
    
    async getOrder(id: string): Promise<Order | null> {
        // Use cache if available, otherwise skip caching
        if (this.cache) {
            const cached = await this.cache.get(id);
            if (cached) return cached;
        }
        
        const order = await this.repository.findById(id);
        
        if (order && this.cache) {
            await this.cache.set(id, order);
        }
        
        // Track if analytics available
        this.analytics?.track("order_viewed", { id });
        
        return order;
    }
}

2. Breaking Circular Dependencies

•When A depends on B and B depends on A
•Constructor injection fails—both need the other during construction
•One dependency can be set via setter after both are constructed

circular-dependency.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
// Circular dependency: A needs B, B needs A
// Constructor injection alone cannot handle this
 
class ServiceA {
    private serviceB?: ServiceB;
    
    // B is set after construction to break the cycle
    setServiceB(serviceB: ServiceB): void {
        this.serviceB = serviceB;
    }
    
    doSomething(): void {
        // Use B after it's been set
        this.serviceB?.collaborate();
    }
}
 
class ServiceB {
    // A is injected through constructor
    constructor(private serviceA: ServiceA) { }
    
    collaborate(): void {
        // B can use A
    }
}
 
// Composition root breaks the cycle
const serviceA = new ServiceA();      // Create A first
const serviceB = new ServiceB(serviceA);  // Create B with A
serviceA.setServiceB(serviceB);       // Now set B on A

Circular Dependencies Are Design Smells

3. Framework Constraints

•Some frameworks require a default constructor
•Legacy frameworks that instantiate objects reflectively
•Serialization/deserialization scenarios
•ORM entities that need a no-arg constructor

framework-constraint.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
// Example: MVC Controller with framework instantiation
// Framework creates controllers with no-arg constructor
 
class OrderController {
    private orderService!: OrderService;
    private authService!: AuthService;
    
    // Framework requires default constructor
    constructor() { }
    
    // Framework calls setters to inject dependencies
    @Inject()
    setOrderService(service: OrderService): void {
        this.orderService = service;
    }
    
    @Inject()
    setAuthService(service: AuthService): void {
        this.authService = service;
    }
    
    @Get("/orders/:id")
    async getOrder(req: Request, res: Response): Promise<void> {
        // By the time this is called, setters have been invoked
        const user = await this.authService.authenticate(req);
        const order = await this.orderService.getOrder(req.params.id);
        res.json(order);
    }
}

4. Reconfigurable Dependencies

•Dependencies that legitimately change during object lifetime
•Strategy pattern with swappable strategies
•Hot-reloadable configuration
•Rare in well-designed systems

Risks and Pitfalls of Setter Injection

Setter Injection introduces significant risks that must be understood and mitigated:

Key Risks

•Incomplete Initialization — Object exists before dependencies are set. Methods called on incomplete objects throw null errors or behave incorrectly.
•Temporal Coupling — Setters must be called in a certain order or before certain methods. This invisible requirement is easy to violate.
•Mutability — Dependencies can be changed after initialization, introducing state changes that are difficult to reason about.
•Hidden Requirements — Unlike constructor parameters, setter-injected dependencies are not visible in the type signature. Callers must know to call setters.
•Thread Safety — Mutable dependencies require synchronization in concurrent environments. Forgetting this causes race conditions.
•Testing Complexity — Tests must call setters in the right order. Forgetting a setter causes cryptic test failures.

risk-incomplete.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// ❌ Risk: Incomplete Initialization
class OrderService {
    private repository?: OrderRepository;
    
    setRepository(repo: OrderRepository) {
        this.repository = repo;
    }
    
    async getOrder(id: string) {
        // If setRepository wasn't called:
        // TypeError: Cannot read 'findById' of undefined
        return this.repository!.findById(id);
    }
}
 
// Mistake: forgot to call setter
const service = new OrderService();
// service.setRepository(...); // Oops!
await service.getOrder("123"); // 💥 Crashes

risk-mutability.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
// ❌ Risk: Mutability and State Changes
class PaymentProcessor {
    private gateway?: PaymentGateway;
    
    setGateway(gw: PaymentGateway) {
        this.gateway = gw;
    }
    
    async process(payment: Payment) {
        return this.gateway!.charge(payment);
    }
}
 
const processor = new PaymentProcessor();
processor.setGateway(new StripeGateway());
 
// Order 1 goes to Stripe
await processor.process(order1);
 
// Mid-execution, someone changes gateway!
processor.setGateway(new PayPalGateway());
 
// Order 2 goes to PayPal unexpectedly
await processor.process(order2); // 🤔

risk-temporal-coupling.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
// ❌ Risk: Temporal Coupling - order matters
 
class ReportGenerator {
    private dataSource?: DataSource;
    private formatter?: Formatter;
    private validator?: Validator;
    
    setDataSource(ds: DataSource) {
        this.dataSource = ds;
    }
    
    setFormatter(fmt: Formatter) {
        // Formatter might depend on dataSource being set first
        if (!this.dataSource) {
            throw new Error("DataSource must be set before Formatter");
        }
        this.formatter = fmt;
    }
    
    setValidator(val: Validator) {
        // Validator might need formatter
        if (!this.formatter) {
            throw new Error("Formatter must be set before Validator");
        }
        this.validator = val;
    }
}
 
// Must call setters in exact order - invisible requirement!
const gen = new ReportGenerator();
gen.setDataSource(new SqlDataSource());
gen.setFormatter(new PdfFormatter());  // Must come after dataSource
gen.setValidator(new StrictValidator()); // Must come after formatter

The Visibility Problem

Defensive Patterns for Safer Setter Injection

When Setter Injection is necessary, apply defensive patterns to mitigate its risks:

Pattern 1: Initialization Validation

•Check that all required dependencies are set before any business method runs
•Throw descriptive errors listing missing dependencies
•Consider an explicit 'initialize()' or 'validate()' method

defensive-validation.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
class OrderService {
    private repository?: OrderRepository;
    private paymentGateway?: PaymentGateway;
    private notifier?: OrderNotifier;
    
    setRepository(repo: OrderRepository): void {
        this.repository = repo;
    }
    
    setPaymentGateway(gateway: PaymentGateway): void {
        this.paymentGateway = gateway;
    }
    
    setNotifier(notifier: OrderNotifier): void {
        this.notifier = notifier;
    }
    
    // Explicit initialization check
    private ensureInitialized(): void {
        const missing: string[] = [];
        
        if (!this.repository) missing.push("OrderRepository");
        if (!this.paymentGateway) missing.push("PaymentGateway");
        if (!this.notifier) missing.push("OrderNotifier");
        
        if (missing.length > 0) {
            throw new Error(
                `OrderService not fully initialized. Missing: ${missing.join(", ")}. ` +
                `Call setRepository(), setPaymentGateway(), setNotifier() first.`
            );
        }
    }
    
    // Business methods call ensureInitialized
    async processOrder(order: Order): Promise<void> {
        this.ensureInitialized();
        
        // Now safe to use - TypeScript knows they're defined
        await this.paymentGateway!.charge(order);
        await this.repository!.save(order);
        await this.notifier!.notify(order);
    }
}

Pattern 2: Builder with Setter Injection

•Use a builder that enforces all dependencies are set
•Builder.build() validates completeness
•Object is only created when fully configured

builder-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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
class OrderServiceBuilder {
    private repository?: OrderRepository;
    private paymentGateway?: PaymentGateway;
    private notifier?: OrderNotifier;
    
    withRepository(repo: OrderRepository): this {
        this.repository = repo;
        return this;
    }
    
    withPaymentGateway(gateway: PaymentGateway): this {
        this.paymentGateway = gateway;
        return this;
    }
    
    withNotifier(notifier: OrderNotifier): this {
        this.notifier = notifier;
        return this;
    }
    
    build(): OrderService {
        // Validate all required dependencies before creating
        if (!this.repository) {
            throw new Error("OrderRepository is required");
        }
        if (!this.paymentGateway) {
            throw new Error("PaymentGateway is required");
        }
        if (!this.notifier) {
            throw new Error("OrderNotifier is required");
        }
        
        // Create with validated dependencies
        const service = new OrderService();
        service.setRepository(this.repository);
        service.setPaymentGateway(this.paymentGateway);
        service.setNotifier(this.notifier);
        
        return service;
    }
}
 
// Usage - build() ensures complete configuration
const service = new OrderServiceBuilder()
    .withRepository(new PostgresOrderRepository())
    .withPaymentGateway(new StripeGateway())
    .withNotifier(new EmailNotifier())
    .build();  // Throws if anything missing

Pattern 3: Immutable After Initialization

•Allow setters only until an 'initialize()' method is called
•After initialization, setters throw exceptions
•Reduces mutability risk while allowing setter-based configuration

immutable-after-init.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
class OrderService {
    private repository?: OrderRepository;
    private paymentGateway?: PaymentGateway;
    private initialized = false;
    
    setRepository(repo: OrderRepository): void {
        if (this.initialized) {
            throw new Error("Cannot modify dependencies after initialization");
        }
        this.repository = repo;
    }
    
    setPaymentGateway(gateway: PaymentGateway): void {
        if (this.initialized) {
            throw new Error("Cannot modify dependencies after initialization");
        }
        this.paymentGateway = gateway;
    }
    
    initialize(): void {
        if (this.initialized) {
            throw new Error("Already initialized");
        }
        
        if (!this.repository || !this.paymentGateway) {
            throw new Error("Cannot initialize: missing dependencies");
        }
        
        this.initialized = true;
        // Object is now immutable - setters will throw
    }
    
    async processOrder(order: Order): Promise<void> {
        if (!this.initialized) {
            throw new Error("Must call initialize() before using");
        }
        
        await this.paymentGateway!.charge(order);
        await this.repository!.save(order);
    }
}
 
// Usage
const service = new OrderService();
service.setRepository(new PostgresOrderRepository());
service.setPaymentGateway(new StripeGateway());
service.initialize();  // Locks configuration
 
// Now setters are blocked
service.setRepository(new OtherRepo()); // 💥 Throws!

Type-Safe Builders

Combining Constructor and Setter Injection

The most robust pattern combines both injection styles:

Required dependencies → Constructor Injection
Optional dependencies → Setter Injection

This hybrid approach gets the best of both worlds: guaranteed completeness for essentials, flexibility for enhancements.

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
71
72
73
74
75
76
// HYBRID PATTERN: Required via constructor, optional via setter
 
class OrderProcessingService {
    // Required dependencies - final after construction
    private readonly repository: OrderRepository;
    private readonly paymentGateway: PaymentGateway;
    
    // Optional dependencies - can be set later
    private cache?: OrderCache;
    private analytics?: AnalyticsTracker;
    private auditLogger?: AuditLogger;
    
    // Constructor takes required dependencies only
    constructor(
        repository: OrderRepository,
        paymentGateway: PaymentGateway
    ) {
        if (!repository) throw new Error("OrderRepository is required");
        if (!paymentGateway) throw new Error("PaymentGateway is required");
        
        this.repository = repository;
        this.paymentGateway = paymentGateway;
    }
    
    // Setters for optional dependencies
    setCache(cache: OrderCache): void {
        this.cache = cache;
    }
    
    setAnalytics(analytics: AnalyticsTracker): void {
        this.analytics = analytics;
    }
    
    setAuditLogger(logger: AuditLogger): void {
        this.auditLogger = logger;
    }
    
    async processOrder(order: Order): Promise<ProcessingResult> {
        // Required dependencies are guaranteed - no null checks
        const paymentResult = await this.paymentGateway.charge(order);
        
        // Optional: check & invalidate cache
        if (this.cache) {
            await this.cache.invalidate(order.customerId);
        }
        
        // Required: save order
        await this.repository.save(order);
        
        // Optional: analytics tracking
        this.analytics?.track("order_processed", {
            orderId: order.id,
            amount: order.total
        });
        
        // Optional: audit logging
        this.auditLogger?.log({
            action: "ORDER_PROCESSED",
            entityId: order.id,
            timestamp: new Date()
        });
        
        return ProcessingResult.success(order);
    }
}
 
// Usage - required in constructor, optional via setters
const service = new OrderProcessingService(
    new PostgresOrderRepository(),
    new StripePaymentGateway()
);
 
// Optionally add enhanced capabilities
service.setCache(new RedisOrderCache());
service.setAnalytics(new MixpanelTracker());
// auditLogger left unset - service works without it

When to Use Which Injection Type
Scenario	Injection Type	Rationale
Core dependencies without which class cannot function	Constructor	Guarantees completeness, immutable
Enhancement dependencies that add features	Setter	Flexibility, optional by nature
Configuration values	Constructor (as config object)	Required for operation
Swappable strategies	Constructor or Setter	Depends on whether initial strategy is required
Circular dependency workaround	Setter (for one direction)	Necessary evil, consider redesign

The Principle

Framework Support for Setter Injection

Major DI frameworks support Setter Injection, though most recommend Constructor Injection as the primary mechanism.

Spring Framework (Java):

spring-setter-injection.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
27
28
29
30
31
32
33
@Service
public class OrderService {
    private OrderRepository repository;
    private AnalyticsTracker analytics;  // Optional
    
    // Constructor injection for required dependency
    @Autowired
    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }
    
    // Setter injection for optional dependency
    // required=false makes it optional
    @Autowired(required = false)
    public void setAnalytics(AnalyticsTracker analytics) {
        this.analytics = analytics;
    }
}
 
// Or using @Inject (JSR-330 standard)
@Service
public class OrderService {
    @Inject
    private OrderRepository repository;  // Field injection
    
    private AnalyticsTracker analytics;
    
    @Inject
    @Optional  // Makes it optional
    public void setAnalytics(AnalyticsTracker analytics) {
        this.analytics = analytics;
    }
}

NestJS (TypeScript):

nestjs-setter-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
@Injectable()
export class OrderService {
    // Constructor injection for required
    constructor(
        private readonly repository: OrderRepository
    ) { }
    
    // Property injection with @Inject decorator
    @Inject()
    @Optional()  // Makes it optional
    private analytics?: AnalyticsTracker;
}
 
// Alternative: Method injection (less common in NestJS)
@Injectable()
export class OrderService {
    private analytics?: AnalyticsTracker;
    
    constructor(
        private readonly repository: OrderRepository
    ) { }
    
    @Inject()
    setAnalytics(@Optional() analytics?: AnalyticsTracker): void {
        this.analytics = analytics;
    }
}

Angular (TypeScript):

angular-setter-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
@Component({
    selector: 'app-order',
    template: '...'
})
export class OrderComponent {
    // Angular primarily uses constructor injection
    constructor(
        private orderService: OrderService
    ) { }
    
    // Optional injection using @Optional decorator
    constructor(
        private orderService: OrderService,
        @Optional() private analytics?: AnalyticsService
    ) { }
    
    // Setter-style with @Input for component inputs
    @Input()
    set config(value: OrderConfig) {
        this.orderConfig = value;
        this.initialize();
    }
}

Field Injection Warning

Testing Classes with Setter Injection

Testing setter-injected classes requires more care than constructor-injected classes. Each test must ensure proper setup:

testing-setter-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
describe("OrderService with setter injection", () => {
    let service: OrderService;
    let mockRepository: jest.Mocked<OrderRepository>;
    let mockGateway: jest.Mocked<PaymentGateway>;
    let mockCache: jest.Mocked<OrderCache>;
    
    beforeEach(() => {
        // Create service with required constructor dependencies
        mockRepository = createMockRepository();
        mockGateway = createMockGateway();
        
        service = new OrderService(mockRepository, mockGateway);
        
        // Optionally set optional dependencies for specific tests
        mockCache = createMockCache();
    });
    
    describe("with all dependencies", () => {
        beforeEach(() => {
            // Set optional dependencies
            service.setCache(mockCache);
        });
        
        it("should use cache when available", async () => {
            mockCache.get.mockResolvedValue(cachedOrder);
            
            const result = await service.getOrder("123");
            
            expect(result).toBe(cachedOrder);
            expect(mockRepository.findById).not.toHaveBeenCalled();
        });
    });
    
    describe("without optional dependencies", () => {
        // Cache not set
        
        it("should work without cache", async () => {
            mockRepository.findById.mockResolvedValue(dbOrder);
            
            const result = await service.getOrder("123");
            
            expect(result).toBe(dbOrder);
            expect(mockRepository.findById).toHaveBeenCalled();
        });
    });
    
    describe("initialization validation", () => {
        it("should throw if required setter not called", async () => {
            // Create service without calling setters for required deps
            const incompleteService = new PartialSetterService();
            // Service uses setter injection for a required dependency
            // Forgot to call setRepository()
            
            await expect(incompleteService.getOrder("123"))
                .rejects.toThrow("Service not initialized");
        });
    });
});
 
// Helper to create properly initialized service for tests
function createFullyInitializedService(): OrderService {
    const service = new OrderService();
    service.setRepository(createMockRepository());
    service.setPaymentGateway(createMockGateway());
    service.setNotifier(createMockNotifier());
    service.initialize();  // If using initialize pattern
    return service;
}

Test Setup Helpers

Summary: Setter Injection Mastery

Setter Injection is a valuable tool when used appropriately. Let's consolidate the essential knowledge:

Key Takeaways

•Mechanics — Dependencies are set via setter methods after object construction. Object exists in incomplete state until setters are called.
•Legitimate uses — Optional dependencies, circular dependency workarounds, framework constraints, reconfigurable strategies.
•Risks — Incomplete initialization, temporal coupling, mutability, hidden requirements, thread-safety concerns.
•Defensive patterns — Initialization validation, builder pattern, immutable-after-init to mitigate risks.
•Hybrid approach — Constructor for required dependencies, setter for optional. Best of both worlds.
•Framework support — All major frameworks support setter injection, often with @Autowired, @Inject, or @Optional annotations.
•Testing — Requires careful setup to ensure all setters are called. Use helper functions to build complete instances.

What's next:

Use Setter Injection Deliberately

3 / 5