System Design (LLD)Service Locator vs Dependency Injection

Service Locator vs Dependency Injection

LevelIntermediate

Duration55 mins

TopicService Locator vs Dependency Injection

2 / 4

Why Service Locator Is Often an Anti-Pattern

The Pattern That Fell From Grace

Service Locator was once celebrated as a clean solution for dependency management. It appeared in influential books, powered major frameworks, and seemed to solve the coupling problem elegantly. Yet today, experienced engineers routinely label it an anti-pattern—a solution that creates more problems than it solves.

This isn't arbitrary fashion or dogma. The shift away from Service Locator reflects hard-won lessons from maintaining large codebases over years. As systems grew in complexity and teams scaled, the pattern's fundamental flaws became increasingly painful. Understanding these flaws deeply will sharpen your architectural judgment and help you recognize similar problematic patterns across software design.

What You Will Learn

By the end of this page, you will understand the specific problems that make Service Locator an anti-pattern: broken encapsulation, global state issues, testing friction, violation of explicit dependencies principle, and the maintainability tax it imposes. You'll see these problems demonstrated in concrete code examples.

Broken Encapsulation

The most fundamental problem with Service Locator is that it breaks encapsulation in a subtle but devastating way. Ironically, while appearing to hide complexity, it actually hides essential information that consumers need to use a class correctly.

The paradox: Service Locator hides implementation details (good) but also hides requirements (bad).

With properly encapsulated code, a class's interface tells you everything you need to use it. The constructor declares: "Give me these things, and I will work." This is a contract—visible, verifiable, and enforceable.

With Service Locator, the constructor lies. It appears to need nothing, but actually needs a properly configured global registry. The real requirements are buried in the implementation.

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
// This constructor LIES about what the class needs
 
class InvoiceGenerator {
    constructor() {
        // Looks like it needs nothing!
    }
 
    async generateInvoice(orderId: string): Promise<Invoice> {
        // Surprise! It actually needs all of these:
        const locator = ServiceLocator.getInstance();
        const orderRepo = locator.resolve<IOrderRepository>(ServiceTokens.OrderRepo);
        const customerRepo = locator.resolve<ICustomerRepository>(ServiceTokens.CustomerRepo);
        const pricingService = locator.resolve<IPricingService>(ServiceTokens.Pricing);
        const taxCalculator = locator.resolve<ITaxCalculator>(ServiceTokens.Tax);
        const templateEngine = locator.resolve<ITemplateEngine>(ServiceTokens.Templates);
        const pdfGenerator = locator.resolve<IPdfGenerator>(ServiceTokens.Pdf);
 
        const order = await orderRepo.findById(orderId);
        const customer = await customerRepo.findById(order.customerId);
        const pricing = await pricingService.calculatePricing(order);
        const tax = await taxCalculator.calculateTax(pricing, customer.address);
        const html = await templateEngine.render('invoice', { order, customer, pricing, tax });
        return await pdfGenerator.generatePdf(html);
    }
}
 
// Consumer's perspective:
function clientCode() {
    // This LOOKS safe - just creating an object
    const generator = new InvoiceGenerator();
    
    // But THIS will explode if ANY of the 6 services aren't registered
    // And we had NO WAY to know that from the constructor
    const invoice = generator.generateInvoice("order-123");
}

Why this matters in practice:

When onboarding new team members, they cannot understand a class's requirements without reading its entire implementation. When refactoring, you cannot know what classes will break when you modify a service registration. When debugging production issues, you cannot trace the dependency chain without examining runtime behavior.

The lying constructor is not a minor inconvenience—it's a fundamental violation of the principle that interfaces should communicate intent.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class ReportGenerator {
    constructor() {
        // Empty - requirements hidden
    }
    
    generate(): Report {
        // Actual requirements:
        // - IDataSource
        // - IFormatter  
        // - IExporter
        // - ILogger
        // - ICache
        // None visible from outside
    }
}
 
// Using this class:
// Q: What does it need?
// A: No idea without reading code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class ReportGenerator {
    constructor(
        private dataSource: IDataSource,
        private formatter: IFormatter,
        private exporter: IExporter,
        private logger: ILogger,
        private cache: ICache
    ) {
        // Requirements are THE SIGNATURE
    }
    
    generate(): Report {
        // Uses declared dependencies
    }
}
 
// Using this class:
// Q: What does it need?
// A: Look at constructor - obvious

Encapsulation Is About Hiding the Right Things

Good encapsulation hides implementation details—how something works. Bad encapsulation (like Service Locator) hides requirements—what something needs. The difference is crucial: hiding 'how' enables flexibility; hiding 'what' creates fragility.

Global State Infection

Service Locator is fundamentally built on global state. The locator must be globally accessible so any component anywhere can resolve dependencies. This creates a constellation of problems that compound as systems grow.

Problems with Global State

•Shared mutable state — The locator can be modified from anywhere, making behavior unpredictable. One part of the code can replace a registration, silently affecting unrelated code.
•Non-deterministic behavior — The same code can behave differently depending on what's registered in the locator when it runs. This makes reasoning about code extremely difficult.
•Test interference — Tests that modify the locator can interfere with each other. Running tests in different orders can produce different results.
•Hidden coupling — Components that appear independent are actually coupled through the shared locator. They're all reading from and potentially writing to the same global registry.
•Initialization ordering — The locator must be configured before any component tries to resolve. Getting this order wrong produces subtle, intermittent failures.

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
// Scenario: Two features independently use the locator
 
// Feature A: User Registration
class RegistrationController {
    async register(email: string, password: string) {
        const locator = ServiceLocator.getInstance();
        const userService = locator.resolve<IUserService>(ServiceTokens.User);
        return userService.createUser(email, password);
    }
}
 
// Feature B: Admin Panel - allows testing with mock services
class AdminController {
    enableTestMode() {
        // Replace real service with mock for testing
        const locator = ServiceLocator.getInstance();
        locator.register(ServiceTokens.User, new MockUserService());
        // Now ALL code using IUserService gets the mock!
    }
    
    disableTestMode() {
        const locator = ServiceLocator.getInstance();
        locator.register(ServiceTokens.User, new RealUserService());
    }
}
 
// The problem in production:
// 1. Admin enables test mode at 2:00pm
// 2. Real user tries to register at 2:01pm
// 3. Registration uses MockUserService (doesn't actually save!)
// 4. Admin disables test mode at 2:05pm
// 5. User's registration was silently lost
 
// This is NOT a contrived example - it's a real category of bugs
// that happens when mutable global state controls behavior

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
// Tests that interact through the global locator
 
describe("PaymentService", () => {
    beforeEach(() => {
        // Each test sets up the locator
        const locator = ServiceLocator.getInstance();
        locator.clear();
        locator.register(ServiceTokens.Logger, new MockLogger());
    });
 
    test("processes payment successfully", async () => {
        const locator = ServiceLocator.getInstance();
        locator.register(ServiceTokens.Gateway, new SuccessGateway());
        
        const service = new PaymentService();
        const result = await service.processPayment(100);
        expect(result.success).toBe(true);
    });
 
    test("handles declined payment", async () => {
        const locator = ServiceLocator.getInstance();
        locator.register(ServiceTokens.Gateway, new DeclineGateway());
        
        const service = new PaymentService();
        const result = await service.processPayment(100);
        expect(result.success).toBe(false);
    });
});
 
// Potential problems:
// 1. If tests run in parallel, they overwrite each other's registrations
// 2. If a test forgets to clear(), it inherits previous test's state
// 3. If a test doesn't register all required services, 
//    it may work if run after another test that did
// 4. Running tests in different order may change results
 
// With DI, each test simply creates objects with the mocks it needs:
test("with DI - processes payment", async () => {
    const service = new PaymentService(new SuccessGateway(), new MockLogger());
    const result = await service.processPayment(100);
    expect(result.success).toBe(true);
});
// No global state. No interference. No ordering issues.

Global State Is Viral

Once you introduce global state, it tends to spread. Components that use the locator encourage other components to do the same. Before long, the entire codebase is infected with implicit coupling through shared mutable state. This is why experienced engineers are so wary of global state—not because of ideology, but because of painful experience.

Testing Friction

One of the most immediate, practical problems with Service Locator is the friction it creates for testing. Testing becomes ceremony-heavy, brittle, and often slower than necessary.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
// Testing a class that uses Service Locator
 
class OrderProcessor {
    constructor() {}
 
    async processOrder(orderId: string): Promise<ProcessingResult> {
        const locator = ServiceLocator.getInstance();
        const orderRepo = locator.resolve<IOrderRepository>(ServiceTokens.OrderRepo);
        const inventory = locator.resolve<IInventoryService>(ServiceTokens.Inventory);
        const payment = locator.resolve<IPaymentService>(ServiceTokens.Payment);
        const shipping = locator.resolve<IShippingService>(ServiceTokens.Shipping);
        const notification = locator.resolve<INotificationService>(ServiceTokens.Notification);
        const audit = locator.resolve<IAuditService>(ServiceTokens.Audit);
 
        const order = await orderRepo.findById(orderId);
        await inventory.reserve(order.items);
        await payment.charge(order.customerId, order.total);
        const tracking = await shipping.schedulePickup(order);
        await notification.sendConfirmation(order.customerId, tracking);
        await audit.logOrderProcessed(orderId);
        
        return { success: true, trackingNumber: tracking };
    }
}
 
// Test: We want to test that a declined payment doesn't ship
 
describe("OrderProcessor", () => {
    let mockOrderRepo: jest.Mocked<IOrderRepository>;
    let mockInventory: jest.Mocked<IInventoryService>;
    let mockPayment: jest.Mocked<IPaymentService>;
    let mockShipping: jest.Mocked<IShippingService>;
    let mockNotification: jest.Mocked<INotificationService>;
    let mockAudit: jest.Mocked<IAuditService>;
 
    beforeEach(() => {
        // CEREMONY: Clear global state
        ServiceLocator.getInstance().clear();
 
        // CEREMONY: Create all mocks (even ones we don't care about)
        mockOrderRepo = createMock<IOrderRepository>();
        mockInventory = createMock<IInventoryService>();
        mockPayment = createMock<IPaymentService>();
        mockShipping = createMock<IShippingService>();
        mockNotification = createMock<INotificationService>();
        mockAudit = createMock<IAuditService>();
 
        // CEREMONY: Register all mocks
        const locator = ServiceLocator.getInstance();
        locator.register(ServiceTokens.OrderRepo, mockOrderRepo);
        locator.register(ServiceTokens.Inventory, mockInventory);
        locator.register(ServiceTokens.Payment, mockPayment);
        locator.register(ServiceTokens.Shipping, mockShipping);
        locator.register(ServiceTokens.Notification, mockNotification);
        locator.register(ServiceTokens.Audit, mockAudit);
    });
 
    afterEach(() => {
        // CEREMONY: Clean up global state
        ServiceLocator.getInstance().clear();
    });
 
    test("does not ship when payment is declined", async () => {
        // Arrange
        mockOrderRepo.findById.mockResolvedValue(testOrder);
        mockInventory.reserve.mockResolvedValue(undefined);
        mockPayment.charge.mockRejectedValue(new PaymentDeclinedError());
 
        // Act & Assert
        const processor = new OrderProcessor();
        await expect(processor.processOrder("order-123"))
            .rejects.toThrow(PaymentDeclinedError);
 
        // Verify shipping was never called
        expect(mockShipping.schedulePickup).not.toHaveBeenCalled();
    });
});

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
// Same class with Dependency Injection
 
class OrderProcessor {
    constructor(
        private readonly orderRepo: IOrderRepository,
        private readonly inventory: IInventoryService,
        private readonly payment: IPaymentService,
        private readonly shipping: IShippingService,
        private readonly notification: INotificationService,
        private readonly audit: IAuditService
    ) {}
 
    async processOrder(orderId: string): Promise<ProcessingResult> {
        const order = await this.orderRepo.findById(orderId);
        await this.inventory.reserve(order.items);
        await this.payment.charge(order.customerId, order.total);
        const tracking = await this.shipping.schedulePickup(order);
        await this.notification.sendConfirmation(order.customerId, tracking);
        await this.audit.logOrderProcessed(orderId);
        
        return { success: true, trackingNumber: tracking };
    }
}
 
// Test: Clean, direct, no ceremony
 
describe("OrderProcessor", () => {
    test("does not ship when payment is declined", async () => {
        // Arrange - only create what we need for THIS test
        const orderRepo = createMock<IOrderRepository>();
        const payment = createMock<IPaymentService>();
        const shipping = createMock<IShippingService>();
        
        orderRepo.findById.mockResolvedValue(testOrder);
        payment.charge.mockRejectedValue(new PaymentDeclinedError());
 
        // Create the processor with mocks - no global state!
        const processor = new OrderProcessor(
            orderRepo,
            createMock<IInventoryService>(),
            payment,
            shipping,
            createMock<INotificationService>(),
            createMock<IAuditService>()
        );
 
        // Act & Assert
        await expect(processor.processOrder("order-123"))
            .rejects.toThrow(PaymentDeclinedError);
 
        expect(shipping.schedulePickup).not.toHaveBeenCalled();
    });
});
 
// Benefits:
// - No beforeEach/afterEach cleanup
// - No global state manipulation
// - Each test is completely isolated
// - Tests can run in parallel safely
// - Dependencies are visible in test code

Testing Friction Comparison
Aspect	Service Locator	Dependency Injection
Setup overhead	Must clear and configure global locator before each test	Direct instantiation with mocks
Cleanup requirement	Must reset global state after each test	No cleanup needed - objects are garbage collected
Test isolation	Tests share global state; isolation requires discipline	Complete isolation by default
Parallel execution	Risky - tests may interfere through shared locator	Safe - no shared mutable state
Discovering dependencies	Must read implementation to know what to mock	Constructor tells you exactly what to provide
Partial mocking	Must register ALL services even if test doesn't use them	Can provide only what's needed for the test

Testing Is Design Feedback

If code is hard to test, it's usually a sign of design problems—not inadequate testing tools. Service Locator makes testing hard because it introduces hidden coupling and global state. Dependency Injection makes testing easy because it makes dependencies explicit and eliminates shared mutable state. The testing friction is a symptom, not the disease.

Violation of Explicit Dependencies Principle

The Explicit Dependencies Principle (EDP) states that a class should explicitly require all the services it needs to function. This principle is violated fundamentally by Service Locator.

"Classes should not reach into the ambient context to get their dependencies. Instead, they should explicitly request (typically via constructor parameters) everything they require."

This isn't an arbitrary rule—it emerges from the principle that code should be honest about its requirements. When code lies about what it needs, everything downstream suffers.

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
// IMPLICIT dependencies (Service Locator) - VIOLATES EDP
 
class ReportGenerator {
    // Constructor claims no requirements
    constructor() {}
    
    generateMonthlyReport(month: Date): Report {
        // Actual requirements hidden inside implementation
        const locator = ServiceLocator.getInstance();
        const dataSource = locator.resolve<IDataSource>(ServiceTokens.Data);
        const aggregator = locator.resolve<IAggregator>(ServiceTokens.Aggregator);
        const formatter = locator.resolve<IFormatter>(ServiceTokens.Formatter);
        const cache = locator.resolve<ICache>(ServiceTokens.Cache);
        // ... uses these to generate report
    }
}
 
// Question: Can I use ReportGenerator?
// Answer: I have no idea. I need to:
//   1. Read the entire implementation
//   2. Find all locator.resolve() calls
//   3. Ensure all those services are registered
//   4. Hope I didn't miss any conditional paths that resolve other services
 
// ---
 
// EXPLICIT dependencies (DI) - FOLLOWS EDP
 
class ReportGenerator {
    // Constructor is a complete requirements specification
    constructor(
        private readonly dataSource: IDataSource,
        private readonly aggregator: IAggregator,
        private readonly formatter: IFormatter,
        private readonly cache: ICache
    ) {}
    
    generateMonthlyReport(month: Date): Report {
        // Uses declared dependencies
        // No surprises
    }
}
 
// Question: Can I use ReportGenerator?
// Answer: Yes, if I can provide IDataSource, IAggregator, IFormatter, and ICache
// The constructor IS the documentation

Why explicit dependencies matter:

Benefits of Explicit Dependencies

•Self-documenting code — The constructor signature tells you everything. New team members can understand requirements without reading implementation.
•IDE support — Modern IDEs can analyze constructors, show required parameters, and even auto-complete valid arguments. They can't analyze calls to a global locator.
•Compiler verification — The compiler ensures all dependencies are provided at construction time. Missing dependencies are compile errors, not runtime surprises.
•Refactoring safety — When you add a dependency, the compiler forces you to update all call sites. With a locator, you might add a resolve() call that silently fails months later in production.
•Dependency graph visibility — With explicit dependencies, tools can analyze and visualize the object graph. With a locator, the graph is invisible until runtime.

The Method Signature Contract

In well-designed code, method signatures are contracts. They specify preconditions (what you must provide) and postconditions (what you'll get back). Service Locator breaks this contract by hiding preconditions inside method bodies. You can only discover what's required by running the code—and hoping it fails clearly when something is missing.

Compile-Time vs Runtime Failures

One of the most practical arguments against Service Locator is the timing of error detection. With Dependency Injection, missing dependencies are caught at compile time. With Service Locator, they're caught at runtime—potentially in production.

The cost of delayed error detection escalates exponentially:

Stage	Cost to Fix	Example
Compile time	Seconds	IDE highlights the error immediately
Unit test	Minutes	Test fails, dev fixes before commit
Integration test	Hours	CI pipeline fails, dev investigates
Staging	Days	QA finds issue, ticket created, dev context-switches
Production	Weeks+	Customer impacted, incident response, postmortem

Service Locator pushes errors as far right in this spectrum as possible.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Dependency Injection: Errors caught at compile time
 
class PaymentProcessor {
    constructor(
        private readonly gateway: IPaymentGateway,
        private readonly logger: ILogger
    ) {}
}
 
// Attempting to create without dependencies:
const processor = new PaymentProcessor(); // TS Error!
// Error: Expected 2 arguments, but got 0
 
// Attempting to create with wrong type:
const processor = new PaymentProcessor("not a gateway", logger); // TS Error!
// Error: Argument of type 'string' is not assignable to parameter of type 'IPaymentGateway'
 
// Attempting to create with null:
const processor = new PaymentProcessor(null, logger); // TS Error (with strictNullChecks)!
// Error: Argument of type 'null' is not assignable
 
// The COMPILER verifies correctness BEFORE code ever runs

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
// Service Locator: Errors caught at runtime (maybe in production!)
 
class PaymentProcessor {
    constructor() {} // Compiles fine!
 
    async process(amount: number): Promise<Result> {
        const locator = ServiceLocator.getInstance();
        // These resolve() calls compile successfully
        // But they may FAIL at runtime
        const gateway = locator.resolve<IPaymentGateway>(ServiceTokens.Gateway);
        const logger = locator.resolve<ILogger>(ServiceTokens.Logger);
        
        logger.log(`Processing ${amount}`);
        return gateway.charge(amount);
    }
}
 
// This compiles and runs fine in development:
const processor = new PaymentProcessor(); // No error!
 
// But in production, someone forgot to register the gateway:
// await processor.process(100);
// Runtime Error: "Service not found: Symbol(PaymentGateway)"
// At 3am. On the busiest day of the year.
 
// Even worse: conditional resolution
class FeatureHandler {
    handle(request: Request): Response {
        const locator = ServiceLocator.getInstance();
        const baseHandler = locator.resolve<IHandler>(ServiceTokens.Handler);
        
        if (request.isPreview) {
            // This branch rarely executes
            // The missing service might not be discovered for months
            const previewHandler = locator.resolve<IPreviewHandler>(
                ServiceTokens.Preview
            );
            return previewHandler.handle(request);
        }
        
        return baseHandler.handle(request);
    }
}

Conditional Branches Are Landmines

The most insidious runtime failures are in conditional branches. If a branch is rarely taken, the missing service registration might not be discovered until the branch executes in production. With DI, even rarely-used constructors are verified at compile time.

The Maintainability Tax

Service Locator imposes a continuous tax on maintenance activities. Every change becomes harder, slower, and riskier because you can't rely on the type system to catch dependency-related errors.

The Ongoing Costs

•Adding dependencies — When you add a new service dependency, you must remember to register it. The compiler won't remind you. Reviews must catch it. Tests must cover all paths that use it.
•Removing dependencies — When you stop using a service, you must remember to remove the registration (or leave dead code). Nothing tells you the service is no longer used.
•Refactoring registrations — Changing service tokens or registration patterns requires searching the codebase for all resolve() calls. IDE refactoring tools can't reliably handle this.
•Understanding code — Every code review requires mentally tracing resolve() calls to understand what a class actually uses. This slows reviews and increases the chance of missing issues.
•Onboarding developers — New team members must learn both the codebase AND the implicit conventions around service registration. With DI, the constructor teaches itself.

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
// Scenario: Adding caching to UserService
 
// === WITH SERVICE LOCATOR ===
 
// Step 1: Add the resolve call (easy to do)
class UserService {
    async getUser(id: string): Promise<User> {
        const locator = ServiceLocator.getInstance();
        const userRepo = locator.resolve<IUserRepository>(ServiceTokens.UserRepo);
        const cache = locator.resolve<ICache>(ServiceTokens.Cache); // NEW!
        
        const cached = await cache.get(`user:${id}`);
        if (cached) return cached;
        
        const user = await userRepo.findById(id);
        await cache.set(`user:${id}`, user);
        return user;
    }
}
 
// Step 2: Remember to register ICache (easy to forget!)
// - If you test locally with cache registered, tests pass
// - If production bootstrap forgets registration, BOOM
// - Nothing verifies this at compile time
 
// Step 3: Update all tests (tedious and error-prone)
// - Must update beforeEach to register cache mock
// - Easy to miss some test files
// - Existing tests might pass if cache is optional
 
// === WITH DEPENDENCY INJECTION ===
 
// Step 1: Add to constructor
class UserService {
    constructor(
        private readonly userRepo: IUserRepository,
        private readonly cache: ICache // NEW - compiler forces update
    ) {}
    
    async getUser(id: string): Promise<User> {
        const cached = await this.cache.get(`user:${id}`);
        if (cached) return cached;
        
        const user = await this.userRepo.findById(id);
        await this.cache.set(`user:${id}`, user);
        return user;
    }
}
 
// Step 2: The compiler immediately shows ALL places you need to update
// - Every test that creates UserService: compile error
// - Every factory or composition root that creates it: compile error
// - IMPOSSIBLE to forget
 
// Step 3: Fix each site (guided by compiler)
// - You literally cannot ship code that doesn't provide the cache

Maintenance Burden Compounds Over Time

Each individual maintenance task might seem manageable with Service Locator. But over years, across hundreds of changes, the accumulated friction becomes enormous. Teams slow down. Confidence erodes. Fear of change sets in. This is death by a thousand cuts—and it's entirely preventable.

Debugging and Reasoning Difficulties

When things go wrong with Service Locator, debugging is significantly harder because the dependency graph is invisible. You cannot trace how a component received a particular implementation without stepping through code or adding logging.

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
// Scenario: PaymentService is using the wrong gateway implementation
// Someone is seeing production payments going to a test gateway
 
class PaymentService {
    constructor() {}
    
    async charge(customerId: string, amount: number): Promise<Receipt> {
        const locator = ServiceLocator.getInstance();
        const gateway = locator.resolve<IPaymentGateway>(ServiceTokens.Gateway);
        
        // Bug: This is using TestGateway in production!
        // But how? Where did that come from?
        return gateway.charge(customerId, amount);
    }
}
 
// To debug, you must:
// 1. Find where ServiceTokens.Gateway is registered
//    - Could be anywhere in the codebase
//    - Might be registered multiple times in different places
//    - Last registration wins, so order matters
// 2. Trace the bootstrap sequence
//    - Which installers ran?
//    - In what order?
//    - Did any code modify registrations later?
// 3. Check for conditional registration
//    - Is there an if(isTest) somewhere that's evaluating wrong?
//    - Environment variable issues?
// 4. Add logging to the locator
//    - Who registered what, when?
//    - What order were things resolved?
 
// Investigation reveals:
function bootstrap() {
    const installers = getInstallerList();
    for (const installer of installers) {
        installer.install(locator);
    }
}
 
// PaymentInstaller.ts registers StripeGateway
// TestInstaller.ts registers TestGateway (should only load in test mode)
// Some environment check is wrong, and TestInstaller loaded in prod
 
// With DI, the debugger shows:
// PaymentService received gateway = TestGateway
// PaymentService was created by PaymentController
// PaymentController received PaymentService from CompositionRoot
// CompositionRoot created PaymentService with gateway = (follow the source)
// Traceable! Visible! Debuggable!

The opacity problem:

Service Locator creates opaque systems where the actual runtime configuration is invisible in the code structure. The code tells you that something will be resolved for a token, but not what. You must mentally execute the bootstrap sequence to know.

Dependency Injection creates transparent systems where the object graph is explicit. You can follow constructor parameters from entry point to leaf, seeing exactly what implementations are provided at each level.

Static Analysis Limitations

Static analysis tools can map DI constructor dependencies automatically, generating architecture diagrams and detecting design issues. Service Locator defeats these tools—the resolve() calls look the same regardless of what service they retrieve. You can't visualize what you can't see at compile time.

Summary: Why Service Locator Is Often an Anti-Pattern

The evidence is overwhelming. Service Locator, while solving the immediate problem of decoupling components from concrete dependencies, introduces a constellation of problems that become increasingly severe as systems and teams scale.

Service Locator Problems Summary

•Broken encapsulation — Hides requirements instead of implementation details, creating 'lying constructors' that appear to need nothing.
•Global state infection — Shared mutable state creates non-determinism, test interference, and hidden coupling.
•Testing friction — Requires ceremony to set up and tear down, risks test interference, and obscures what needs mocking.
•Violates explicit dependencies — Classes don't honestly declare what they need; you must read implementation to discover requirements.
•Runtime-only verification — Missing services are only detected when code executes, potentially in production.
•Maintainability tax — Every change is harder because the compiler can't help verify dependency-related correctness.
•Debugging difficulty — The invisible dependency graph makes tracing issues much harder than with explicit wiring.

What's next:

We've seen the general problems with Service Locator. The next page dives deep into one specific, critical issue: hidden dependencies. This problem deserves its own examination because it's the root cause of many practical failures with Service Locator—and understanding it deeply will inform your thinking about API design in general.

Page Complete

You now understand why Service Locator is considered an anti-pattern despite its historical significance. These aren't theoretical concerns—they're distilled lessons from millions of hours of maintenance, debugging, and refactoring in real codebases. Next, we'll examine the hidden dependencies problem in depth.

2 / 4

Loading learning content...

System Design (LLD)Service Locator vs Dependency Injection

Service Locator vs Dependency Injection

LevelIntermediate

Duration55 mins

TopicService Locator vs Dependency Injection

2 / 4

Why Service Locator Is Often an Anti-Pattern

The Pattern That Fell From Grace

What You Will Learn

Broken Encapsulation

The paradox: Service Locator hides implementation details (good) but also hides requirements (bad).

With Service Locator, the constructor lies. It appears to need nothing, but actually needs a properly configured global registry. The real requirements are buried in the implementation.

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
// This constructor LIES about what the class needs
 
class InvoiceGenerator {
    constructor() {
        // Looks like it needs nothing!
    }
 
    async generateInvoice(orderId: string): Promise<Invoice> {
        // Surprise! It actually needs all of these:
        const locator = ServiceLocator.getInstance();
        const orderRepo = locator.resolve<IOrderRepository>(ServiceTokens.OrderRepo);
        const customerRepo = locator.resolve<ICustomerRepository>(ServiceTokens.CustomerRepo);
        const pricingService = locator.resolve<IPricingService>(ServiceTokens.Pricing);
        const taxCalculator = locator.resolve<ITaxCalculator>(ServiceTokens.Tax);
        const templateEngine = locator.resolve<ITemplateEngine>(ServiceTokens.Templates);
        const pdfGenerator = locator.resolve<IPdfGenerator>(ServiceTokens.Pdf);
 
        const order = await orderRepo.findById(orderId);
        const customer = await customerRepo.findById(order.customerId);
        const pricing = await pricingService.calculatePricing(order);
        const tax = await taxCalculator.calculateTax(pricing, customer.address);
        const html = await templateEngine.render('invoice', { order, customer, pricing, tax });
        return await pdfGenerator.generatePdf(html);
    }
}
 
// Consumer's perspective:
function clientCode() {
    // This LOOKS safe - just creating an object
    const generator = new InvoiceGenerator();
    
    // But THIS will explode if ANY of the 6 services aren't registered
    // And we had NO WAY to know that from the constructor
    const invoice = generator.generateInvoice("order-123");
}

Why this matters in practice:

The lying constructor is not a minor inconvenience—it's a fundamental violation of the principle that interfaces should communicate intent.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class ReportGenerator {
    constructor() {
        // Empty - requirements hidden
    }
    
    generate(): Report {
        // Actual requirements:
        // - IDataSource
        // - IFormatter  
        // - IExporter
        // - ILogger
        // - ICache
        // None visible from outside
    }
}
 
// Using this class:
// Q: What does it need?
// A: No idea without reading code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class ReportGenerator {
    constructor(
        private dataSource: IDataSource,
        private formatter: IFormatter,
        private exporter: IExporter,
        private logger: ILogger,
        private cache: ICache
    ) {
        // Requirements are THE SIGNATURE
    }
    
    generate(): Report {
        // Uses declared dependencies
    }
}
 
// Using this class:
// Q: What does it need?
// A: Look at constructor - obvious

Encapsulation Is About Hiding the Right Things

Global State Infection

Problems with Global State

•Shared mutable state — The locator can be modified from anywhere, making behavior unpredictable. One part of the code can replace a registration, silently affecting unrelated code.
•Non-deterministic behavior — The same code can behave differently depending on what's registered in the locator when it runs. This makes reasoning about code extremely difficult.
•Test interference — Tests that modify the locator can interfere with each other. Running tests in different orders can produce different results.
•Hidden coupling — Components that appear independent are actually coupled through the shared locator. They're all reading from and potentially writing to the same global registry.
•Initialization ordering — The locator must be configured before any component tries to resolve. Getting this order wrong produces subtle, intermittent failures.

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
// Scenario: Two features independently use the locator
 
// Feature A: User Registration
class RegistrationController {
    async register(email: string, password: string) {
        const locator = ServiceLocator.getInstance();
        const userService = locator.resolve<IUserService>(ServiceTokens.User);
        return userService.createUser(email, password);
    }
}
 
// Feature B: Admin Panel - allows testing with mock services
class AdminController {
    enableTestMode() {
        // Replace real service with mock for testing
        const locator = ServiceLocator.getInstance();
        locator.register(ServiceTokens.User, new MockUserService());
        // Now ALL code using IUserService gets the mock!
    }
    
    disableTestMode() {
        const locator = ServiceLocator.getInstance();
        locator.register(ServiceTokens.User, new RealUserService());
    }
}
 
// The problem in production:
// 1. Admin enables test mode at 2:00pm
// 2. Real user tries to register at 2:01pm
// 3. Registration uses MockUserService (doesn't actually save!)
// 4. Admin disables test mode at 2:05pm
// 5. User's registration was silently lost
 
// This is NOT a contrived example - it's a real category of bugs
// that happens when mutable global state controls behavior

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
// Tests that interact through the global locator
 
describe("PaymentService", () => {
    beforeEach(() => {
        // Each test sets up the locator
        const locator = ServiceLocator.getInstance();
        locator.clear();
        locator.register(ServiceTokens.Logger, new MockLogger());
    });
 
    test("processes payment successfully", async () => {
        const locator = ServiceLocator.getInstance();
        locator.register(ServiceTokens.Gateway, new SuccessGateway());
        
        const service = new PaymentService();
        const result = await service.processPayment(100);
        expect(result.success).toBe(true);
    });
 
    test("handles declined payment", async () => {
        const locator = ServiceLocator.getInstance();
        locator.register(ServiceTokens.Gateway, new DeclineGateway());
        
        const service = new PaymentService();
        const result = await service.processPayment(100);
        expect(result.success).toBe(false);
    });
});
 
// Potential problems:
// 1. If tests run in parallel, they overwrite each other's registrations
// 2. If a test forgets to clear(), it inherits previous test's state
// 3. If a test doesn't register all required services, 
//    it may work if run after another test that did
// 4. Running tests in different order may change results
 
// With DI, each test simply creates objects with the mocks it needs:
test("with DI - processes payment", async () => {
    const service = new PaymentService(new SuccessGateway(), new MockLogger());
    const result = await service.processPayment(100);
    expect(result.success).toBe(true);
});
// No global state. No interference. No ordering issues.

Global State Is Viral

Testing Friction

One of the most immediate, practical problems with Service Locator is the friction it creates for testing. Testing becomes ceremony-heavy, brittle, and often slower than necessary.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
// Testing a class that uses Service Locator
 
class OrderProcessor {
    constructor() {}
 
    async processOrder(orderId: string): Promise<ProcessingResult> {
        const locator = ServiceLocator.getInstance();
        const orderRepo = locator.resolve<IOrderRepository>(ServiceTokens.OrderRepo);
        const inventory = locator.resolve<IInventoryService>(ServiceTokens.Inventory);
        const payment = locator.resolve<IPaymentService>(ServiceTokens.Payment);
        const shipping = locator.resolve<IShippingService>(ServiceTokens.Shipping);
        const notification = locator.resolve<INotificationService>(ServiceTokens.Notification);
        const audit = locator.resolve<IAuditService>(ServiceTokens.Audit);
 
        const order = await orderRepo.findById(orderId);
        await inventory.reserve(order.items);
        await payment.charge(order.customerId, order.total);
        const tracking = await shipping.schedulePickup(order);
        await notification.sendConfirmation(order.customerId, tracking);
        await audit.logOrderProcessed(orderId);
        
        return { success: true, trackingNumber: tracking };
    }
}
 
// Test: We want to test that a declined payment doesn't ship
 
describe("OrderProcessor", () => {
    let mockOrderRepo: jest.Mocked<IOrderRepository>;
    let mockInventory: jest.Mocked<IInventoryService>;
    let mockPayment: jest.Mocked<IPaymentService>;
    let mockShipping: jest.Mocked<IShippingService>;
    let mockNotification: jest.Mocked<INotificationService>;
    let mockAudit: jest.Mocked<IAuditService>;
 
    beforeEach(() => {
        // CEREMONY: Clear global state
        ServiceLocator.getInstance().clear();
 
        // CEREMONY: Create all mocks (even ones we don't care about)
        mockOrderRepo = createMock<IOrderRepository>();
        mockInventory = createMock<IInventoryService>();
        mockPayment = createMock<IPaymentService>();
        mockShipping = createMock<IShippingService>();
        mockNotification = createMock<INotificationService>();
        mockAudit = createMock<IAuditService>();
 
        // CEREMONY: Register all mocks
        const locator = ServiceLocator.getInstance();
        locator.register(ServiceTokens.OrderRepo, mockOrderRepo);
        locator.register(ServiceTokens.Inventory, mockInventory);
        locator.register(ServiceTokens.Payment, mockPayment);
        locator.register(ServiceTokens.Shipping, mockShipping);
        locator.register(ServiceTokens.Notification, mockNotification);
        locator.register(ServiceTokens.Audit, mockAudit);
    });
 
    afterEach(() => {
        // CEREMONY: Clean up global state
        ServiceLocator.getInstance().clear();
    });
 
    test("does not ship when payment is declined", async () => {
        // Arrange
        mockOrderRepo.findById.mockResolvedValue(testOrder);
        mockInventory.reserve.mockResolvedValue(undefined);
        mockPayment.charge.mockRejectedValue(new PaymentDeclinedError());
 
        // Act & Assert
        const processor = new OrderProcessor();
        await expect(processor.processOrder("order-123"))
            .rejects.toThrow(PaymentDeclinedError);
 
        // Verify shipping was never called
        expect(mockShipping.schedulePickup).not.toHaveBeenCalled();
    });
});

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
// Same class with Dependency Injection
 
class OrderProcessor {
    constructor(
        private readonly orderRepo: IOrderRepository,
        private readonly inventory: IInventoryService,
        private readonly payment: IPaymentService,
        private readonly shipping: IShippingService,
        private readonly notification: INotificationService,
        private readonly audit: IAuditService
    ) {}
 
    async processOrder(orderId: string): Promise<ProcessingResult> {
        const order = await this.orderRepo.findById(orderId);
        await this.inventory.reserve(order.items);
        await this.payment.charge(order.customerId, order.total);
        const tracking = await this.shipping.schedulePickup(order);
        await this.notification.sendConfirmation(order.customerId, tracking);
        await this.audit.logOrderProcessed(orderId);
        
        return { success: true, trackingNumber: tracking };
    }
}
 
// Test: Clean, direct, no ceremony
 
describe("OrderProcessor", () => {
    test("does not ship when payment is declined", async () => {
        // Arrange - only create what we need for THIS test
        const orderRepo = createMock<IOrderRepository>();
        const payment = createMock<IPaymentService>();
        const shipping = createMock<IShippingService>();
        
        orderRepo.findById.mockResolvedValue(testOrder);
        payment.charge.mockRejectedValue(new PaymentDeclinedError());
 
        // Create the processor with mocks - no global state!
        const processor = new OrderProcessor(
            orderRepo,
            createMock<IInventoryService>(),
            payment,
            shipping,
            createMock<INotificationService>(),
            createMock<IAuditService>()
        );
 
        // Act & Assert
        await expect(processor.processOrder("order-123"))
            .rejects.toThrow(PaymentDeclinedError);
 
        expect(shipping.schedulePickup).not.toHaveBeenCalled();
    });
});
 
// Benefits:
// - No beforeEach/afterEach cleanup
// - No global state manipulation
// - Each test is completely isolated
// - Tests can run in parallel safely
// - Dependencies are visible in test code

Testing Friction Comparison
Aspect	Service Locator	Dependency Injection
Setup overhead	Must clear and configure global locator before each test	Direct instantiation with mocks
Cleanup requirement	Must reset global state after each test	No cleanup needed - objects are garbage collected
Test isolation	Tests share global state; isolation requires discipline	Complete isolation by default
Parallel execution	Risky - tests may interfere through shared locator	Safe - no shared mutable state
Discovering dependencies	Must read implementation to know what to mock	Constructor tells you exactly what to provide
Partial mocking	Must register ALL services even if test doesn't use them	Can provide only what's needed for the test

Testing Is Design Feedback

Violation of Explicit Dependencies Principle

The Explicit Dependencies Principle (EDP) states that a class should explicitly require all the services it needs to function. This principle is violated fundamentally by Service Locator.

"Classes should not reach into the ambient context to get their dependencies. Instead, they should explicitly request (typically via constructor parameters) everything they require."

This isn't an arbitrary rule—it emerges from the principle that code should be honest about its requirements. When code lies about what it needs, everything downstream suffers.

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
// IMPLICIT dependencies (Service Locator) - VIOLATES EDP
 
class ReportGenerator {
    // Constructor claims no requirements
    constructor() {}
    
    generateMonthlyReport(month: Date): Report {
        // Actual requirements hidden inside implementation
        const locator = ServiceLocator.getInstance();
        const dataSource = locator.resolve<IDataSource>(ServiceTokens.Data);
        const aggregator = locator.resolve<IAggregator>(ServiceTokens.Aggregator);
        const formatter = locator.resolve<IFormatter>(ServiceTokens.Formatter);
        const cache = locator.resolve<ICache>(ServiceTokens.Cache);
        // ... uses these to generate report
    }
}
 
// Question: Can I use ReportGenerator?
// Answer: I have no idea. I need to:
//   1. Read the entire implementation
//   2. Find all locator.resolve() calls
//   3. Ensure all those services are registered
//   4. Hope I didn't miss any conditional paths that resolve other services
 
// ---
 
// EXPLICIT dependencies (DI) - FOLLOWS EDP
 
class ReportGenerator {
    // Constructor is a complete requirements specification
    constructor(
        private readonly dataSource: IDataSource,
        private readonly aggregator: IAggregator,
        private readonly formatter: IFormatter,
        private readonly cache: ICache
    ) {}
    
    generateMonthlyReport(month: Date): Report {
        // Uses declared dependencies
        // No surprises
    }
}
 
// Question: Can I use ReportGenerator?
// Answer: Yes, if I can provide IDataSource, IAggregator, IFormatter, and ICache
// The constructor IS the documentation

Why explicit dependencies matter:

Benefits of Explicit Dependencies

•Self-documenting code — The constructor signature tells you everything. New team members can understand requirements without reading implementation.
•IDE support — Modern IDEs can analyze constructors, show required parameters, and even auto-complete valid arguments. They can't analyze calls to a global locator.
•Compiler verification — The compiler ensures all dependencies are provided at construction time. Missing dependencies are compile errors, not runtime surprises.
•Refactoring safety — When you add a dependency, the compiler forces you to update all call sites. With a locator, you might add a resolve() call that silently fails months later in production.
•Dependency graph visibility — With explicit dependencies, tools can analyze and visualize the object graph. With a locator, the graph is invisible until runtime.

The Method Signature Contract

Compile-Time vs Runtime Failures

The cost of delayed error detection escalates exponentially:

Stage	Cost to Fix	Example
Compile time	Seconds	IDE highlights the error immediately
Unit test	Minutes	Test fails, dev fixes before commit
Integration test	Hours	CI pipeline fails, dev investigates
Staging	Days	QA finds issue, ticket created, dev context-switches
Production	Weeks+	Customer impacted, incident response, postmortem

Service Locator pushes errors as far right in this spectrum as possible.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Dependency Injection: Errors caught at compile time
 
class PaymentProcessor {
    constructor(
        private readonly gateway: IPaymentGateway,
        private readonly logger: ILogger
    ) {}
}
 
// Attempting to create without dependencies:
const processor = new PaymentProcessor(); // TS Error!
// Error: Expected 2 arguments, but got 0
 
// Attempting to create with wrong type:
const processor = new PaymentProcessor("not a gateway", logger); // TS Error!
// Error: Argument of type 'string' is not assignable to parameter of type 'IPaymentGateway'
 
// Attempting to create with null:
const processor = new PaymentProcessor(null, logger); // TS Error (with strictNullChecks)!
// Error: Argument of type 'null' is not assignable
 
// The COMPILER verifies correctness BEFORE code ever runs

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
// Service Locator: Errors caught at runtime (maybe in production!)
 
class PaymentProcessor {
    constructor() {} // Compiles fine!
 
    async process(amount: number): Promise<Result> {
        const locator = ServiceLocator.getInstance();
        // These resolve() calls compile successfully
        // But they may FAIL at runtime
        const gateway = locator.resolve<IPaymentGateway>(ServiceTokens.Gateway);
        const logger = locator.resolve<ILogger>(ServiceTokens.Logger);
        
        logger.log(`Processing ${amount}`);
        return gateway.charge(amount);
    }
}
 
// This compiles and runs fine in development:
const processor = new PaymentProcessor(); // No error!
 
// But in production, someone forgot to register the gateway:
// await processor.process(100);
// Runtime Error: "Service not found: Symbol(PaymentGateway)"
// At 3am. On the busiest day of the year.
 
// Even worse: conditional resolution
class FeatureHandler {
    handle(request: Request): Response {
        const locator = ServiceLocator.getInstance();
        const baseHandler = locator.resolve<IHandler>(ServiceTokens.Handler);
        
        if (request.isPreview) {
            // This branch rarely executes
            // The missing service might not be discovered for months
            const previewHandler = locator.resolve<IPreviewHandler>(
                ServiceTokens.Preview
            );
            return previewHandler.handle(request);
        }
        
        return baseHandler.handle(request);
    }
}

Conditional Branches Are Landmines

The Maintainability Tax

Service Locator imposes a continuous tax on maintenance activities. Every change becomes harder, slower, and riskier because you can't rely on the type system to catch dependency-related errors.

The Ongoing Costs

•Adding dependencies — When you add a new service dependency, you must remember to register it. The compiler won't remind you. Reviews must catch it. Tests must cover all paths that use it.
•Removing dependencies — When you stop using a service, you must remember to remove the registration (or leave dead code). Nothing tells you the service is no longer used.
•Refactoring registrations — Changing service tokens or registration patterns requires searching the codebase for all resolve() calls. IDE refactoring tools can't reliably handle this.
•Understanding code — Every code review requires mentally tracing resolve() calls to understand what a class actually uses. This slows reviews and increases the chance of missing issues.
•Onboarding developers — New team members must learn both the codebase AND the implicit conventions around service registration. With DI, the constructor teaches itself.

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
// Scenario: Adding caching to UserService
 
// === WITH SERVICE LOCATOR ===
 
// Step 1: Add the resolve call (easy to do)
class UserService {
    async getUser(id: string): Promise<User> {
        const locator = ServiceLocator.getInstance();
        const userRepo = locator.resolve<IUserRepository>(ServiceTokens.UserRepo);
        const cache = locator.resolve<ICache>(ServiceTokens.Cache); // NEW!
        
        const cached = await cache.get(`user:${id}`);
        if (cached) return cached;
        
        const user = await userRepo.findById(id);
        await cache.set(`user:${id}`, user);
        return user;
    }
}
 
// Step 2: Remember to register ICache (easy to forget!)
// - If you test locally with cache registered, tests pass
// - If production bootstrap forgets registration, BOOM
// - Nothing verifies this at compile time
 
// Step 3: Update all tests (tedious and error-prone)
// - Must update beforeEach to register cache mock
// - Easy to miss some test files
// - Existing tests might pass if cache is optional
 
// === WITH DEPENDENCY INJECTION ===
 
// Step 1: Add to constructor
class UserService {
    constructor(
        private readonly userRepo: IUserRepository,
        private readonly cache: ICache // NEW - compiler forces update
    ) {}
    
    async getUser(id: string): Promise<User> {
        const cached = await this.cache.get(`user:${id}`);
        if (cached) return cached;
        
        const user = await this.userRepo.findById(id);
        await this.cache.set(`user:${id}`, user);
        return user;
    }
}
 
// Step 2: The compiler immediately shows ALL places you need to update
// - Every test that creates UserService: compile error
// - Every factory or composition root that creates it: compile error
// - IMPOSSIBLE to forget
 
// Step 3: Fix each site (guided by compiler)
// - You literally cannot ship code that doesn't provide the cache

Maintenance Burden Compounds Over Time

Debugging and Reasoning Difficulties

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
// Scenario: PaymentService is using the wrong gateway implementation
// Someone is seeing production payments going to a test gateway
 
class PaymentService {
    constructor() {}
    
    async charge(customerId: string, amount: number): Promise<Receipt> {
        const locator = ServiceLocator.getInstance();
        const gateway = locator.resolve<IPaymentGateway>(ServiceTokens.Gateway);
        
        // Bug: This is using TestGateway in production!
        // But how? Where did that come from?
        return gateway.charge(customerId, amount);
    }
}
 
// To debug, you must:
// 1. Find where ServiceTokens.Gateway is registered
//    - Could be anywhere in the codebase
//    - Might be registered multiple times in different places
//    - Last registration wins, so order matters
// 2. Trace the bootstrap sequence
//    - Which installers ran?
//    - In what order?
//    - Did any code modify registrations later?
// 3. Check for conditional registration
//    - Is there an if(isTest) somewhere that's evaluating wrong?
//    - Environment variable issues?
// 4. Add logging to the locator
//    - Who registered what, when?
//    - What order were things resolved?
 
// Investigation reveals:
function bootstrap() {
    const installers = getInstallerList();
    for (const installer of installers) {
        installer.install(locator);
    }
}
 
// PaymentInstaller.ts registers StripeGateway
// TestInstaller.ts registers TestGateway (should only load in test mode)
// Some environment check is wrong, and TestInstaller loaded in prod
 
// With DI, the debugger shows:
// PaymentService received gateway = TestGateway
// PaymentService was created by PaymentController
// PaymentController received PaymentService from CompositionRoot
// CompositionRoot created PaymentService with gateway = (follow the source)
// Traceable! Visible! Debuggable!

The opacity problem:

Static Analysis Limitations

Summary: Why Service Locator Is Often an Anti-Pattern

Service Locator Problems Summary

•Broken encapsulation — Hides requirements instead of implementation details, creating 'lying constructors' that appear to need nothing.
•Global state infection — Shared mutable state creates non-determinism, test interference, and hidden coupling.
•Testing friction — Requires ceremony to set up and tear down, risks test interference, and obscures what needs mocking.
•Violates explicit dependencies — Classes don't honestly declare what they need; you must read implementation to discover requirements.
•Runtime-only verification — Missing services are only detected when code executes, potentially in production.
•Maintainability tax — Every change is harder because the compiler can't help verify dependency-related correctness.
•Debugging difficulty — The invisible dependency graph makes tracing issues much harder than with explicit wiring.

What's next:

Page Complete

2 / 4