Recap of Dependency Injection from DIP Chapter - Dependency Injection Revisited | OneNoughtOne

0/246

System Design (LLD)Dependency Injection Deep Dive

Dependency Injection Revisited

LevelIntermediate

Duration60 mins

TopicDependency Injection Deep Dive

1 / 4

Recap of Dependency Injection from DIP Chapter

Returning to Dependency Injection

In the Dependency Inversion Principle chapter, we introduced Dependency Injection as a technique for achieving dependency inversion. We established that DI allows high-level modules to depend on abstractions rather than concrete implementations, promoting loose coupling and enhanced testability.

This chapter takes that foundation and builds upon it comprehensively. Before we explore advanced DI patterns, injection variants, and IoC containers, we must first solidify our understanding of the core concepts. This page serves as both a refresher and a bridge—reconnecting you with essential DI principles while preparing you for the deeper exploration ahead.

What You Will Learn

By the end of this page, you will have a crystal-clear understanding of DI fundamentals: what DI is, why it matters, and how it relates to the broader Dependency Inversion Principle. You'll be positioned to explore advanced DI techniques with confidence.

The Dependency Problem

To understand Dependency Injection, we must first understand the problem it solves. In object-oriented programming, objects rarely exist in isolation. They collaborate with other objects to accomplish their responsibilities. This collaboration creates dependencies—one object requires another to function.

Consider a straightforward example: an OrderService needs to validate payments. The naive approach creates the dependency directly within the class:

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
class PaymentValidator {
    validate(payment: Payment): ValidationResult {
        // Database call to check payment details
        // External API call to fraud detection service
        // Complex business rule validation
        return { isValid: true, errors: [] };
    }
}
 
class OrderService {
    private paymentValidator: PaymentValidator;
    
    constructor() {
        // The problem: OrderService creates its own dependency
        this.paymentValidator = new PaymentValidator();
    }
    
    processOrder(order: Order): OrderResult {
        const validation = this.paymentValidator.validate(order.payment);
        
        if (!validation.isValid) {
            return { success: false, errors: validation.errors };
        }
        
        // Process the order...
        return { success: true, orderId: generateId() };
    }
}

At first glance, this code appears reasonable—it compiles, it runs, it processes orders. But beneath the surface, this design creates several significant problems that compound as the system evolves:

Problems with Internal Dependency Creation

•Untestable in Isolation — To test OrderService, you must also execute PaymentValidator, which makes database calls and external API calls. Unit tests become integration tests. Fast feedback becomes slow feedback. Test environments become complex.
•Rigid Coupling — OrderService is welded to PaymentValidator. Changing the payment validation strategy requires modifying OrderService itself, violating the Open-Closed Principle.
•Hidden Dependencies — Looking at the OrderService constructor reveals nothing about its requirements. The dependency is hidden in the implementation, making the class harder to understand and use correctly.
•No Runtime Flexibility — Every OrderService instance uses the same PaymentValidator. Environment-specific validators (production vs. testing vs. staging) require code changes.
•Cascading Changes — If PaymentValidator's constructor changes (adding a database connection, for instance), OrderService must change too. Changes ripple through the codebase.

The Hidden Cost

When objects create their own dependencies, they don't just depend on those collaborators—they depend on the entire construction graph. If PaymentValidator needs a DatabaseConnection, and DatabaseConnection needs a ConnectionPool, then OrderService implicitly depends on all of them, even though it never directly references them.

The Dependency Inversion Principle Recap

The Dependency Inversion Principle (DIP) provides the conceptual foundation for solving these dependency problems. As the 'D' in SOLID, DIP articulates two complementary rules:

The Two Rules of DIP

•High-level modules should not depend on low-level modules. Both should depend on abstractions.
•Abstractions should not depend on details. Details should depend on abstractions.

Understanding 'High-Level' and 'Low-Level':

In the DIP context, 'high-level' and 'low-level' don't refer to complexity or importance. They refer to abstraction distance from input/output boundaries:

High-level modules embody business policies and orchestrate workflows. OrderService is high-level—it expresses the business concept of processing an order.
Low-level modules handle technical details and interact with external systems. PaymentValidator is lower-level—it deals with database queries and API calls.

Without DIP, high-level policy modules depend on low-level mechanism modules. This inverted relationship means changes in technical details force changes in business logic—exactly backward from how change should flow.

The Inversion:

The word 'inversion' refers to flipping the traditional dependency direction. In procedural and naive OO code, high-level modules depend on low-level modules. DIP inverts this: both depend on abstractions that exist at the high-level module's layer. The abstraction IPaymentValidator is owned by the high-level code and implemented by the low-level code.

This inversion has profound implications:

The high-level module defines what it needs (the interface)
The low-level module provides what the high-level module needs (the implementation)
The high-level module never knows about the low-level module's existence
Substituting implementations becomes trivial

Interface Ownership Matters

A common mistake is placing interfaces in the same package as their implementations. For true dependency inversion, the interface should live in the high-level module's package. The low-level module depends on the high-level module to get the interface definition—not the other way around.

Dependency Injection as a DIP Implementation Technique

The Dependency Inversion Principle tells us what to do: depend on abstractions. Dependency Injection tells us how to do it: provide dependencies from outside the consuming class.

Definition:

Dependency Injection is a technique where an object's dependencies are provided (injected) by an external entity rather than created internally. The object declares what it needs; the external entity supplies it.

This simple inversion of control—from 'I create what I need' to 'I receive what I need'—enables DIP compliance and brings numerous practical benefits.

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
// The abstraction: owned by high-level code
interface IPaymentValidator {
    validate(payment: Payment): ValidationResult;
}
 
// The implementation: provides what high-level code needs
class PaymentValidator implements IPaymentValidator {
    constructor(
        private readonly database: DatabaseConnection,
        private readonly fraudApi: FraudDetectionClient
    ) {}
    
    validate(payment: Payment): ValidationResult {
        // Implementation details hidden from consumers
        const fraudCheck = this.fraudApi.checkPayment(payment);
        const dbCheck = this.database.query('SELECT...');
        return { isValid: fraudCheck.passed && dbCheck.valid, errors: [] };
    }
}
 
// The consumer: depends only on abstraction, receives dependency
class OrderService {
    // Dependency declared explicitly
    constructor(private readonly paymentValidator: IPaymentValidator) {}
    
    processOrder(order: Order): OrderResult {
        // OrderService knows nothing about PaymentValidator's internals
        const validation = this.paymentValidator.validate(order.payment);
        
        if (!validation.isValid) {
            return { success: false, errors: validation.errors };
        }
        
        return { success: true, orderId: generateId() };
    }
}
 
// Composition: somewhere outside, dependencies are wired together
const database = new DatabaseConnection(connectionString);
const fraudApi = new FraudDetectionClient(apiKey);
const validator = new PaymentValidator(database, fraudApi);
const orderService = new OrderService(validator);  // Injection happens here

Notice the structural changes:

An interface appears — IPaymentValidator defines the contract
Constructor accepts dependency — OrderService receives its validator
No new in consumer — OrderService never instantiates PaymentValidator
Composition happens externally — Object graph is assembled outside business logic

These changes may seem superficial, but they fundamentally alter the code's characteristics.

Without DI

•Class controls its dependencies
•Dependencies hidden in implementation
•Testing requires real implementations
•Changing implementations requires code changes
•Classes are coupled to concrete types
•Object graph assembled ad-hoc

With DI

•External entity controls dependencies
•Dependencies visible in constructor
•Testing uses mock/stub implementations
•Changing implementations requires configuration
•Classes coupled only to abstractions
•Object graph assembled centrally

The Three Collaborators in Dependency Injection

Every DI scenario involves three distinct roles. Understanding these roles clarifies how DI works mechanically and helps you identify where DI should be applied in your designs.

The Three DI Collaborators

•The Dependent (Consumer/Client) — The object that needs a dependency. It declares what it requires (through constructor parameters, setters, or interface methods) and uses the dependency to perform its work. Example: OrderService depends on payment validation.
•The Dependency (Service/Collaborator) — The object being depended upon. It provides some capability that the dependent needs. The dependent knows only about the dependency's interface, not its implementation. Example: PaymentValidator provides validation capability.
•The Injector (Assembler/Container) — The external entity that creates dependencies and provides them to dependents. This might be manual composition code, a factory, or a full IoC container. Example: The main() function or an IoC container like InversifyJS.

The Injector's Responsibilities:

The injector is the orchestrator of object creation. It knows the complete object graph—which classes exist, how they're constructed, and how they relate to each other. This responsibility includes:

Creating instances — Instantiating both dependents and their dependencies
Managing order — Ensuring dependencies exist before dependents that need them
Resolving types — Deciding which implementation satisfies which abstraction
Managing lifecycles — Controlling when objects are created, shared, or destroyed

In simple applications, the injector is just a main() function or a composition root. In complex applications, IoC containers automate these responsibilities.

The Injector is Not the Dependent

A critical distinction: the dependent never plays the injector role for its own dependencies. If OrderService created PaymentValidator, it would be acting as an injector for itself, defeating the purpose. The dependent is passive—it receives, it doesn't create.

Benefits of Dependency Injection Revisited

Let's consolidate and deepen our understanding of why DI matters. These benefits aren't theoretical—they manifest concretely in codebases that embrace DI versus those that don't.

DI Benefits: From Abstract to Concrete
Benefit	What It Means	Concrete Example
Loose Coupling	Classes know interfaces, not implementations	OrderService works with any IPaymentValidator—production, test, or mock
Testability	Dependencies can be replaced with test doubles	Unit test OrderService with a stub validator that returns predetermined results in 0ms
Flexibility	Behavior changes through configuration, not code	Switch from Stripe to PayPal by swapping the PaymentValidator implementation
Explicit Dependencies	Requirements are visible in constructors	Reading OrderService's constructor instantly reveals it needs a payment validator
Single Responsibility	Classes aren't also factories for their dependencies	OrderService processes orders—it doesn't configure database connections
Separation of Concerns	Construction is separated from use	Business logic stays pure; wiring happens in composition root

Testability in Depth:

Testability deserves special attention because it's often the first tangible benefit teams experience when adopting DI. Consider testing OrderService:

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
// Without DI: Testing is painful
class OrderServiceWithoutDI {
    private validator = new PaymentValidator(); // Hardcoded
    
    // To test this, we need:
    // - A running database
    // - A real or mocked fraud API
    // - Slower tests (network calls)
    // - Complex test environment setup
}
 
// With DI: Testing is simple
class OrderServiceWithDI {
    constructor(private validator: IPaymentValidator) {}
}
 
// Test: Pure unit test, fast, isolated
describe('OrderService', () => {
    it('should reject orders with invalid payments', () => {
        // Arrange: Create a stub that always returns invalid
        const stubValidator: IPaymentValidator = {
            validate: () => ({ isValid: false, errors: ['Insufficient funds'] })
        };
        const service = new OrderServiceWithDI(stubValidator);
        
        // Act
        const result = service.processOrder(testOrder);
        
        // Assert
        expect(result.success).toBe(false);
        expect(result.errors).toContain('Insufficient funds');
    });
    
    it('should process valid orders successfully', () => {
        // Arrange: Create a stub that always returns valid
        const stubValidator: IPaymentValidator = {
            validate: () => ({ isValid: true, errors: [] })
        };
        const service = new OrderServiceWithDI(stubValidator);
        
        // Act
        const result = service.processOrder(testOrder);
        
        // Assert
        expect(result.success).toBe(true);
        expect(result.orderId).toBeDefined();
    });
});

Tests Run in Milliseconds

These tests execute in milliseconds because they involve no database, no network, no external services. Each test controls exactly what the validator returns, enabling comprehensive coverage of all edge cases. This is the power of testability through DI.

Key Terminology

Before proceeding to advanced topics, let's establish precise definitions for terms that will appear throughout this chapter. Clear terminology prevents confusion and enables precise communication.

Essential DI Terminology

•Dependency — An object that another object needs to function. When A requires B to work, B is a dependency of A.
•Dependent — An object that requires dependencies. Also called the consumer or client.
•Injection — The act of providing a dependency to a dependent from an external source.
•Inversion of Control (IoC) — A design principle where the control of object creation and dependency resolution is inverted from the consumer to a framework or container.
•IoC Container — A framework that automates dependency injection, managing object creation, dependency resolution, and lifecycle.
•Composition Root — The single location in an application where object graphs are assembled and dependencies are wired together.
•Service — In DI context, often refers to a dependency being injected (the 'service' provides something to the consumer).
•Registration — The process of configuring an IoC container with the types it should manage and how to create them.
•Resolution — The process of obtaining an instance of a type from an IoC container, with all its dependencies satisfied.
•Lifetime/Scope — How long a dependency instance lives and whether it's shared across consumers (transient, scoped, singleton).

Terminology Overlap

Different frameworks and communities use slightly different terms. 'Service' vs 'Dependency', 'Consumer' vs 'Client' vs 'Dependent', 'Container' vs 'Kernel'. The concepts are the same; only the labels vary. Focus on understanding the roles, not memorizing specific terminology.

Common Misconceptions About DI

As DI has become mainstream, several misconceptions have emerged. Let's address these directly to prevent confusion as we explore advanced techniques.

Misconceptions and Corrections

•'DI requires a container' — Incorrect. DI is a technique; containers are tools. You can practice DI with pure manual wiring. Many applications do DI without any container framework.
•'DI is only for testing' — Partially true. Testability is a major benefit, but DI also enables runtime flexibility, configuration-driven behavior, and cleaner architecture. Don't adopt DI solely for testing.
•'More injection is always better' — Incorrect. Over-injection creates complexity without benefit. Not every collaborator needs to be injected. Value objects, utilities, and stable dependencies often don't need DI.
•'DI eliminates all coupling' — Incorrect. DI eliminates coupling to concrete implementations, not to abstractions. You still depend on interfaces. DI manages coupling; it doesn't eliminate it.
•'DI and IoC are the same thing' — Incorrect. IoC is a broad principle (inverting control flow). DI is a specific technique for achieving IoC with dependencies. All DI is IoC, but not all IoC is DI.
•'DI makes code inherently better' — Incorrect. DI is a tool with appropriate uses. Misapplied DI (injecting everything, complex container configurations, over-abstraction) can make code worse, not better.

Pragmatism Over Dogma

DI is not a religion. Not every object needs dependencies injected. Simple applications may not need containers. Use DI where it provides clear benefits—testability, flexibility, clarity—and skip it where it adds ceremony without value.

Summary: Foundation for the Deep Dive

We've revisited the essential concepts that underpin Dependency Injection:

The dependency problem: Objects creating their own dependencies leads to tight coupling, hidden relationships, and testing difficulties.
DIP foundation: High-level and low-level modules should both depend on abstractions, not on each other.
DI as technique: Providing dependencies from outside enables DIP compliance practically.
Three collaborators: Dependent, dependency, and injector each play distinct roles.
Core benefits: Loose coupling, testability, flexibility, explicit dependencies.

This foundation prepares us for deeper exploration. In the pages ahead, we'll examine:

How DI operates as both a technique and a principle
The full benefits of DI: flexibility, testability, maintainability
Defining appropriate scopes and boundaries for DI in your systems

Page Complete

You now have a refreshed, deepened understanding of Dependency Injection fundamentals. The concepts from DIP chapter are solidified, and you're ready to explore DI as both technique and principle in the next page.