DI Anti-Patterns - Learning Module

Loading content...

0/246

Constructor Over-Injection

The Smell of a God Class in Disguise

You're reviewing code and encounter a class constructor that takes 15 dependencies. Each dependency is injected cleanly through the constructor, following all the "best practices" for dependency injection. The IoC container wires everything up automatically. Syntactically, this code is immaculate. Semantically, it's a disaster.

This is constructor over-injection—the anti-pattern where a class demands so many dependencies that it signals deep architectural problems. Paradoxically, strict adherence to DI best practices can reveal rather than cause this problem. The constructor's overwhelming parameter list is a symptom, screaming that the class is doing too much.

The Paradox of Good Practices

Constructor injection forces dependencies to be explicit. This visibility is good—it surfaces design flaws that would otherwise hide in Service Locator calls or static methods. When you see 10+ constructor parameters, don't blame DI. Thank it for revealing the underlying violation of Single Responsibility Principle.

What You Will Learn

By the end of this page, you will understand the root causes of constructor over-injection, recognize when dependency counts become problematic, apply systematic refactoring strategies to decompose bloated classes, and distinguish between legitimate complexity and fixable design flaws.

Defining Constructor Over-Injection

Constructor over-injection occurs when a class requires so many dependencies through its constructor that it violates the principle of having a single, well-defined responsibility. While there's no absolute number that defines "too many," industry convention suggests that more than 3-4 dependencies warrants scrutiny, and more than 7 almost always indicates a design problem.

Let's examine what this looks like in practice:

OrderService.ts (Anti-Pattern)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 🚨 ANTI-PATTERN: Constructor Over-Injection
// This class has grown to handle far too many responsibilities
 
class OrderService {
    constructor(
        private readonly orderRepository: IOrderRepository,
        private readonly paymentGateway: IPaymentGateway,
        private readonly inventoryService: IInventoryService,
        private readonly shippingCalculator: IShippingCalculator,
        private readonly taxCalculator: ITaxCalculator,
        private readonly discountEngine: IDiscountEngine,
        private readonly loyaltyPointsService: ILoyaltyPointsService,
        private readonly notificationService: INotificationService,
        private readonly auditLogger: IAuditLogger,
        private readonly fraudDetector: IFraudDetector,
        private readonly currencyConverter: ICurrencyConverter,
        private readonly cacheService: ICacheService,
        private readonly configurationManager: IConfigurationManager,
        private readonly metricsCollector: IMetricsCollector,
        private readonly eventBus: IEventBus
    ) {}
    
    // Hundreds of lines of methods handling all aspects of orders...
}

At first glance, this class follows DI best practices: all dependencies are explicit, injected through the constructor, and each uses interface abstraction. But the sheer number of dependencies tells a story. This OrderService is doing the work of several classes:

Order persistence and retrieval
Payment processing
Inventory management
Shipping and logistics
Tax calculation
Promotional discounts
Customer loyalty programs
User notifications
Compliance auditing
Security and fraud prevention
Internationalization
Performance optimization
System configuration
Observability

The Naming Red Flag

When a class's name ends with a generic suffix like 'Service', 'Manager', or 'Handler', it often becomes a dumping ground for loosely related functionality. The vagueness of the name permits scope creep. Specific names like 'PaymentProcessor' or 'OrderFulfillmentCoordinator' naturally constrain what belongs in the class.

Why Over-Injection Happens

Constructor over-injection doesn't happen overnight. It's the cumulative result of many small, seemingly reasonable decisions. Understanding these root causes is essential for prevention:

Root Causes of Constructor Over-Injection

•Organic Growth Without Refactoring — A class starts small but gains features over years. Each new requirement adds 'just one more dependency.' Nobody notices the cumulative effect until it's severe.
•Fear of Creating New Classes — Developers hesitate to introduce new abstractions, believing it adds complexity. Ironically, they create more complexity by overloading existing classes.
•Misunderstanding of Single Responsibility — Some interpret SRP as 'a class should do one thing,' but that 'one thing' grows to encompass entire business domains.
•Procedural Thinking in OOP Contexts — Developers trained in procedural programming may create 'God classes' that orchestrate everything, treating OOP as procedural code with extra syntax.
•Lack of Domain Modeling — Without clear domain boundaries, responsibilities blur together. The 'Order' concept expands to include everything tangentially related to orders.
•Pressure to Deliver Quickly — Project timelines discourage thoughtful decomposition. Adding a dependency to an existing class is faster than designing a new collaboration.
•Insufficient Design Review — Without architectural oversight, classes bloat unnoticed. By the time anyone reviews, the refactoring cost seems prohibitive.

The Boiling Frog Syndrome:

Imagine a class that starts with 3 dependencies—perfectly reasonable. A new feature adds a 4th. Then a 5th for logging. A 6th for caching. A 7th for metrics. Each addition feels justified in isolation. But the class has transformed from a focused unit into an sprawling aggregate of unrelated concerns.

This is why dependency count should be a tracked metric in code reviews. Not as a hard rule, but as a tripwire that triggers discussion: "This class now has 8 dependencies. Is this still cohesive?"

The 'Just One More' Trap

The most dangerous phrase in software architecture is 'It's just one more dependency.' That rationale has created countless God classes. Every dependency adds coupling, complexity, and cognitive load. The cumulative weight eventually crushes maintainability.

The Consequences of Over-Injection

Constructor over-injection isn't merely an aesthetic problem—it creates tangible engineering costs across multiple dimensions:

Impact Analysis: Over-Injection Consequences
Dimension	Impact	Business Cost
Testing	Unit tests require mocking 15+ dependencies. Test setup dominates test logic. Mock configuration becomes a maintenance burden.	Testing time increases 5-10x. Developers skip edge cases or avoid testing altogether.
Cognitive Load	Developers must understand all dependencies and their interactions to modify the class safely.	Onboarding time doubles. Senior developers become bottlenecks.
Change Safety	Any modification risks unintended side effects across the many responsibilities. Coupling is implicit but pervasive.	Bug rates increase. Production incidents become more frequent.
Reusability	The class cannot be used in different contexts without dragging all dependencies. It becomes monolithic.	Code duplication increases. Similar functionality is reimplemented elsewhere.
Compile/Build Time	Changes to any dependency trigger recompilation. The class depends on half the codebase.	Developer feedback loops slow. Productivity drops.
Team Ownership	Multiple teams' concerns are coupled in one class. Ownership boundaries are unclear.	Coordination overhead increases. Teams block each other.

The Testing Nightmare Illustrated:

Consider writing a unit test for the OrderService shown earlier. Before testing any actual business logic, you must construct mocks for 15 dependencies:

OrderService.test.ts (Problematic)
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
// 🚨 ANTI-PATTERN: Test setup overwhelms actual test logic
describe('OrderService', () => {
    let service: OrderService;
    
    // Mock declarations for FIFTEEN dependencies
    let mockOrderRepository: jest.Mocked<IOrderRepository>;
    let mockPaymentGateway: jest.Mocked<IPaymentGateway>;
    let mockInventoryService: jest.Mocked<IInventoryService>;
    let mockShippingCalculator: jest.Mocked<IShippingCalculator>;
    let mockTaxCalculator: jest.Mocked<ITaxCalculator>;
    let mockDiscountEngine: jest.Mocked<IDiscountEngine>;
    let mockLoyaltyPointsService: jest.Mocked<ILoyaltyPointsService>;
    let mockNotificationService: jest.Mocked<INotificationService>;
    let mockAuditLogger: jest.Mocked<IAuditLogger>;
    let mockFraudDetector: jest.Mocked<IFraudDetector>;
    let mockCurrencyConverter: jest.Mocked<ICurrencyConverter>;
    let mockCacheService: jest.Mocked<ICacheService>;
    let mockConfigurationManager: jest.Mocked<IConfigurationManager>;
    let mockMetricsCollector: jest.Mocked<IMetricsCollector>;
    let mockEventBus: jest.Mocked<IEventBus>;
 
    beforeEach(() => {
        // 50+ lines of mock initialization...
        mockOrderRepository = createMockOrderRepository();
        mockPaymentGateway = createMockPaymentGateway();
        mockInventoryService = createMockInventoryService();
        // ... 12 more mock setups ...
        
        service = new OrderService(
            mockOrderRepository,
            mockPaymentGateway,
            mockInventoryService,
            mockShippingCalculator,
            mockTaxCalculator,
            mockDiscountEngine,
            mockLoyaltyPointsService,
            mockNotificationService,
            mockAuditLogger,
            mockFraudDetector,
            mockCurrencyConverter,
            mockCacheService,
            mockConfigurationManager,
            mockMetricsCollector,
            mockEventBus
        );
    });
 
    it('should apply discount to order', () => {
        // The actual test logic is dwarfed by setup
        mockDiscountEngine.calculateDiscount.mockReturnValue(10);
        
        const result = service.calculateOrderTotal(testOrder);
        
        expect(result.discount).toBe(10);
    });
});

The Test Code Ratio Problem

When test setup is 50+ lines but test assertions are 3-5 lines, the signal-to-noise ratio is catastrophic. Developers lose track of what's actually being tested. Tests become maintenance burdens rather than safety nets. This invariably leads to abandoned testing efforts.

Recognizing Over-Injection: Diagnostic Signals

Beyond simple dependency counting, several patterns signal constructor over-injection. Train yourself to recognize these diagnostic signals:

Diagnostic Signals

•Method-Specific Dependencies — Some dependencies are only used by one or two methods. These methods likely belong in a separate class.
•Logical Groupings — Dependencies cluster into conceptual groups (e.g., notification-related, persistence-related). Each cluster may deserve its own abstraction.
•Low Cohesion — Methods in the class don't share dependencies. Method A uses deps 1-3, method B uses deps 4-6, method C uses deps 7-9. This indicates three classes masquerading as one.
•Constructor Parameter Objects — When teams create 'parameter objects' to consolidate constructor parameters, they're treating symptoms, not causes.
•Difficulty Naming the Class — If you struggle to name the class with a precise, non-generic noun, its responsibilities are probably too broad.
•Fear of Modification — When developers fear changing the class because 'it affects too much,' cohesion has collapsed.
•Cross-Cutting Concerns Mingled with Domain Logic — Logging, caching, metrics, and security concerns are mixed with business logic dependencies.

The Method-Dependency Matrix:

A powerful diagnostic technique is to map which methods use which dependencies. Create a matrix with methods as rows and dependencies as columns. Mark each cell where a method uses a dependency:

Method	OrderRepo	Payment	Inventory	Shipping	Tax	Discount	Notify
createOrder()	✓	✓	✓
calculateSubtotal()	✓				✓	✓
processPayment()	✓	✓
arrangeShipping()	✓			✓			✓

If you see non-overlapping blocks of checkmarks, those blocks represent separate classes waiting to be extracted. The matrix visualizes what intuition struggles to grasp.

Cohesion Score

Calculate a rough cohesion score: for each dependency, count how many methods use it, then average across all dependencies. If the average is less than half the total methods, cohesion is weak. This quantifies the 'smell' and helps justify refactoring to stakeholders.

Refactoring Strategies: Decomposing Bloated Classes

Once you've identified constructor over-injection, systematic refactoring is required. Here are proven strategies, ordered from simplest to most transformative:

Strategy 1: Extract Cohesive Classes

Identify groups of dependencies that are always used together. Extract them into focused classes with clear responsibilities:

OrderPricingService.ts (Extracted)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// ✅ GOOD: Focused class with cohesive dependencies
class OrderPricingService {
    constructor(
        private readonly taxCalculator: ITaxCalculator,
        private readonly discountEngine: IDiscountEngine,
        private readonly currencyConverter: ICurrencyConverter
    ) {}
    
    calculateOrderTotal(order: Order, customerContext: CustomerContext): PricingResult {
        const subtotal = order.items.reduce((sum, item) => sum + item.price * item.quantity, 0);
        const discount = this.discountEngine.calculateDiscount(order, customerContext);
        const taxableAmount = subtotal - discount;
        const tax = this.taxCalculator.calculateTax(taxableAmount, order.shippingAddress);
        
        return {
            subtotal: this.currencyConverter.convert(subtotal, customerContext.currency),
            discount: this.currencyConverter.convert(discount, customerContext.currency),
            tax: this.currencyConverter.convert(tax, customerContext.currency),
            total: this.currencyConverter.convert(taxableAmount + tax, customerContext.currency),
        };
    }
}

Strategy 2: Facade for Orchestration

When a class legitimately orchestrates multiple subsystems, consider whether it should be a thin facade that delegates to focused components:

OrderFacade.ts (Orchestrator)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// ✅ GOOD: Thin facade orchestrating focused services
class OrderFacade {
    constructor(
        private readonly orderRepository: IOrderRepository,
        private readonly pricingService: OrderPricingService,
        private readonly fulfillmentService: OrderFulfillmentService,
        private readonly notificationService: OrderNotificationService
    ) {}
    
    // Note: This facade has 4 high-level dependencies, not 15 low-level ones
    
    async submitOrder(order: Order, customer: Customer): Promise<OrderResult> {
        // Orchestration logic only - no implementation details
        const pricing = this.pricingService.calculateOrderTotal(order, customer);
        const savedOrder = await this.orderRepository.save({ ...order, ...pricing });
        await this.fulfillmentService.initiateFulfillment(savedOrder);
        await this.notificationService.notifyOrderConfirmation(savedOrder, customer);
        
        return { orderId: savedOrder.id, ...pricing };
    }
}

Strategy 3: Decorator for Cross-Cutting Concerns

Extract logging, caching, metrics, and auditing into decorators that wrap the core service:

LoggingOrderServiceDecorator.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
// ✅ GOOD: Cross-cutting concerns extracted to decorator
class LoggingOrderServiceDecorator implements IOrderService {
    constructor(
        private readonly inner: IOrderService,
        private readonly auditLogger: IAuditLogger
    ) {}
    
    async submitOrder(order: Order, customer: Customer): Promise<OrderResult> {
        this.auditLogger.logOperation('order.submit.started', { orderId: order.id });
        
        try {
            const result = await this.inner.submitOrder(order, customer);
            this.auditLogger.logOperation('order.submit.completed', { 
                orderId: order.id, 
                total: result.total 
            });
            return result;
        } catch (error) {
            this.auditLogger.logOperation('order.submit.failed', { 
                orderId: order.id, 
                error: error.message 
            });
            throw error;
        }
    }
}
 
// Composition at wiring time:
const orderService = new LoggingOrderServiceDecorator(
    new MetricsOrderServiceDecorator(
        new CachingOrderServiceDecorator(
            new OrderServiceCore(/* only 4 dependencies */),
            cacheService
        ),
        metricsCollector
    ),
    auditLogger
);

Strategy Selection Guide

•Use Extract Class when dependencies cluster into cohesive groups with shared data or operations.
•Use Facade when the class orchestrates multiple subsystems but doesn't implement business logic itself.
•Use Decorator when you're mixing cross-cutting concerns (logging, caching, metrics) with domain logic.
•Use Domain Events when dependencies exist only to notify other systems of state changes.
•Use Method Injection when a dependency is used by only one public method (pass it as a parameter instead).

The Refactored Result

Let's see the complete transformation of our original 15-dependency OrderService into a well-structured system:

RefactoredOrderSystem.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
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
// ✅ GOOD: Decomposed into focused, cohesive classes
 
// 1. Pricing responsibility
class OrderPricingService {
    constructor(
        private readonly taxCalculator: ITaxCalculator,
        private readonly discountEngine: IDiscountEngine,
        private readonly currencyConverter: ICurrencyConverter
    ) {}
    
    calculateTotal(order: Order, context: CustomerContext): PricingResult { ... }
}
 
// 2. Fulfillment responsibility  
class OrderFulfillmentService {
    constructor(
        private readonly inventoryService: IInventoryService,
        private readonly shippingCalculator: IShippingCalculator,
        private readonly loyaltyPointsService: ILoyaltyPointsService
    ) {}
    
    async initiateFulfillment(order: Order): Promise<FulfillmentResult> { ... }
}
 
// 3. Payment responsibility
class OrderPaymentService {
    constructor(
        private readonly paymentGateway: IPaymentGateway,
        private readonly fraudDetector: IFraudDetector
    ) {}
    
    async processPayment(order: Order, paymentInfo: PaymentInfo): Promise<PaymentResult> { ... }
}
 
// 4. Notification responsibility
class OrderNotificationService {
    constructor(
        private readonly notificationService: INotificationService,
        private readonly eventBus: IEventBus
    ) {}
    
    async notifyOrderConfirmation(order: Order, customer: Customer): Promise<void> { ... }
}
 
// 5. Core orchestrator with HIGH-LEVEL dependencies
class OrderService {
    constructor(
        private readonly orderRepository: IOrderRepository,
        private readonly pricingService: OrderPricingService,
        private readonly fulfillmentService: OrderFulfillmentService,
        private readonly paymentService: OrderPaymentService,
        private readonly notificationService: OrderNotificationService
    ) {}
    
    async submitOrder(order: Order, customer: Customer, paymentInfo: PaymentInfo): Promise<OrderResult> {
        const pricing = this.pricingService.calculateTotal(order, customer.context);
        const payment = await this.paymentService.processPayment(order, paymentInfo);
        const savedOrder = await this.orderRepository.save({ ...order, ...pricing, payment });
        await this.fulfillmentService.initiateFulfillment(savedOrder);
        await this.notificationService.notifyOrderConfirmation(savedOrder, customer);
        
        return savedOrder;
    }
}
 
// 6. Cross-cutting concerns applied via decorators at composition root
// (logging, caching, metrics wrapped around OrderService)

Before Refactoring

•1 class with 15 dependencies
•Testing requires 15+ mocks
•Any change risks side effects
•Single team owns everything
•Cannot reuse components
•Modifications require domain expertise in all areas

After Refactoring

•6 classes with 2-5 dependencies each
•Each test mocks 2-5 dependencies
•Changes isolated to single class
•Different teams can own components
•Components reusable across contexts
•Modifications require focused expertise

Prevention Strategies

Prevention is far less costly than refactoring. Embed these practices into your development workflow to prevent constructor over-injection from occurring:

Prevention Practices

•Dependency Count Threshold in CI — Configure static analysis to warn when a class exceeds 4 constructor parameters and fail at 7+.
•Code Review Checklists — Add 'Does this change increase constructor parameters?' to review templates.
•Design Reviews for New Classes — Before implementing, sketch dependencies. If the sketch shows more than 4, redesign first.
•Continuous Refactoring — Budget 20% of sprint capacity for refactoring. Don't wait for 'refactoring sprints' that never come.
•Domain-Driven Design — Clear bounded contexts and aggregates naturally limit class scope. Invest in domain modeling.
•Regular Dependency Audits — Monthly, run a script that lists classes by dependency count. Track trends.
•Pair Programming on Complex Features — Two perspectives catch bloat earlier than solo development.

Automated Enforcement

Tools like ArchUnit (Java), NDepend (.NET), or custom ESLint rules (TypeScript) can automatically enforce dependency limits. Catching violations in CI is infinitely cheaper than discovering them in production code reviews.

Summary: Constructor Over-Injection

Let's consolidate the essential insights from this exploration of constructor over-injection:

Key Takeaways

•Over-injection is a symptom, not a cause — The real problem is violation of Single Responsibility Principle. DI makes it visible.
•More than 4 dependencies warrants scrutiny — Use this threshold as a trigger for design review, not as a hard rule.
•Testing burden is the most immediate cost — When test setup overwhelms test logic, refactoring has become urgent.
•Use the method-dependency matrix — This visualization reveals cohesion failures that intuition misses.
•Extract cohesive classes, then compose — Transform one bloated class into multiple focused ones coordinated by a thin facade.
•Decorators handle cross-cutting concerns — Remove logging, caching, and metrics from business classes entirely.
•Prevention through enforcement — Static analysis in CI catches bloat before it merges.

What's Next:

Constructor over-injection is visible and relatively straightforward to fix. Our next topic, circular dependencies, is far more insidious—it can hide for months, emerging only as cryptic stack overflows or initialization failures. We'll explore how circular dependencies arise and systematic strategies to eliminate them.

Page Complete

You now understand constructor over-injection—the anti-pattern of injecting too many dependencies, its causes, consequences, diagnostic signals, and refactoring strategies. Next, we'll tackle circular dependencies, which represent an even more fundamental design problem.