Service Locator Pattern - Service Locator vs Dependency Injection | OneNoughtOne

0/290

System Design (LLD)Service Locator vs Dependency Injection

Service Locator vs Dependency Injection

LevelIntermediate

Duration55 mins

TopicService Locator vs Dependency Injection

1 / 4

Service Locator Pattern

The Global Registry Approach

Before Dependency Injection became the dominant paradigm for managing object dependencies, another pattern held sway in enterprise software development: the Service Locator. This pattern provides a centralized registry that components query to obtain their dependencies—a seemingly elegant solution that promises simplicity but often delivers complexity in disguise.

Understanding Service Locator is essential for two reasons. First, you will encounter this pattern in legacy codebases and certain frameworks that use it extensively. Second, understanding why it fell from favor illuminates the deeper principles that make Dependency Injection superior for most use cases. This contrast sharpens your ability to make informed architectural decisions.

What You Will Learn

By the end of this page, you will understand the Service Locator pattern in depth—its mechanics, historical context, implementation variations, and the superficial appeal that led to its widespread adoption. This foundation prepares you to critically evaluate when it fails and, surprisingly, when it might still be appropriate.

What Is a Service Locator?

A Service Locator is a design pattern that provides a centralized registry—a global point of access—where components can look up their dependencies at runtime. Instead of having dependencies passed into a class (injection), the class actively reaches out to the locator to retrieve what it needs.

The fundamental mechanics are straightforward:

Registration: Services are registered with the locator, typically during application startup
Resolution: Components query the locator to retrieve registered services
Abstraction: The locator typically returns interfaces, allowing implementations to vary

Conceptually, you can think of the Service Locator as a sophisticated global dictionary that maps service types (or names) to their implementations. Components don't need to know where their dependencies come from or how they're constructed—they just ask the locator.

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
// A simple Service Locator implementation
class ServiceLocator {
    private static instance: ServiceLocator;
    private services: Map<string, any> = new Map();
 
    // Singleton access - the locator is globally accessible
    static getInstance(): ServiceLocator {
        if (!ServiceLocator.instance) {
            ServiceLocator.instance = new ServiceLocator();
        }
        return ServiceLocator.instance;
    }
 
    // Register a service with a key
    register<T>(key: string, service: T): void {
        this.services.set(key, service);
    }
 
    // Retrieve a service by key
    resolve<T>(key: string): T {
        const service = this.services.get(key);
        if (!service) {
            throw new Error(`Service not found: ${key}`);
        }
        return service as T;
    }
 
    // Check if a service is registered
    has(key: string): boolean {
        return this.services.has(key);
    }
 
    // Clear all registrations (useful for testing)
    clear(): void {
        this.services.clear();
    }
}

This basic implementation demonstrates the pattern's core mechanics. In practice, Service Locators often include additional features:

Lifetime management: Creating new instances (transient) vs returning singletons
Lazy initialization: Deferring service creation until first resolution
Type-safe registration: Using types or interfaces as keys instead of strings
Hierarchical scopes: Child locators that inherit from parents
Factory registration: Registering factory functions instead of instances

The Singleton Connection

Notice that the Service Locator is typically implemented as a Singleton. This is fundamental to the pattern—it provides global access so any component anywhere can resolve dependencies. This global nature is both its strength (convenience) and weakness (hidden coupling), as we'll explore in detail.

Type-Safe Service Locator Implementations

String-based keys are error-prone—typos cause runtime failures, and there's no compile-time verification. Production Service Locators typically use type information for safer resolution. Let's examine a more sophisticated 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
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
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
// Service identifier using symbols for type safety
interface ServiceIdentifier<T> {
    readonly id: symbol;
    readonly _type?: T; // Phantom type for type inference
}
 
// Factory function type
type ServiceFactory<T> = () => T;
 
// Registration record
interface ServiceRecord<T> {
    factory?: ServiceFactory<T>;
    instance?: T;
    singleton: boolean;
}
 
class TypedServiceLocator {
    private static instance: TypedServiceLocator;
    private services: Map<symbol, ServiceRecord<any>> = new Map();
 
    private constructor() {} // Enforce singleton
 
    static getInstance(): TypedServiceLocator {
        if (!TypedServiceLocator.instance) {
            TypedServiceLocator.instance = new TypedServiceLocator();
        }
        return TypedServiceLocator.instance;
    }
 
    // Create a service identifier
    static createIdentifier<T>(name: string): ServiceIdentifier<T> {
        return { id: Symbol(name) };
    }
 
    // Register a singleton instance
    registerSingleton<T>(
        identifier: ServiceIdentifier<T>,
        instance: T
    ): void {
        this.services.set(identifier.id, {
            instance,
            singleton: true
        });
    }
 
    // Register a factory for transient instances
    registerTransient<T>(
        identifier: ServiceIdentifier<T>,
        factory: ServiceFactory<T>
    ): void {
        this.services.set(identifier.id, {
            factory,
            singleton: false
        });
    }
 
    // Register a factory that creates a singleton on first resolve
    registerLazySingleton<T>(
        identifier: ServiceIdentifier<T>,
        factory: ServiceFactory<T>
    ): void {
        this.services.set(identifier.id, {
            factory,
            singleton: true
        });
    }
 
    // Resolve a service
    resolve<T>(identifier: ServiceIdentifier<T>): T {
        const record = this.services.get(identifier.id);
        
        if (!record) {
            throw new Error(`Service not registered: ${identifier.id.toString()}`);
        }
 
        if (record.singleton) {
            if (record.instance === undefined && record.factory) {
                record.instance = record.factory();
            }
            return record.instance as T;
        } else {
            if (!record.factory) {
                throw new Error(`No factory for transient service`);
            }
            return record.factory();
        }
    }
 
    // Optional resolution (returns undefined if not found)
    tryResolve<T>(identifier: ServiceIdentifier<T>): T | undefined {
        try {
            return this.resolve(identifier);
        } catch {
            return undefined;
        }
    }
}

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
// Define service interfaces
interface ILogger {
    log(message: string): void;
    error(message: string): void;
}
 
interface IUserRepository {
    findById(id: string): Promise<User | null>;
    save(user: User): Promise<void>;
}
 
interface IEmailService {
    send(to: string, subject: string, body: string): Promise<void>;
}
 
// Create identifiers (typically in a central file)
const ServiceTokens = {
    Logger: TypedServiceLocator.createIdentifier<ILogger>("Logger"),
    UserRepository: TypedServiceLocator.createIdentifier<IUserRepository>("UserRepository"),
    EmailService: TypedServiceLocator.createIdentifier<IEmailService>("EmailService"),
};
 
// Bootstrap phase - register services
function configureServices(): void {
    const locator = TypedServiceLocator.getInstance();
 
    // Register singleton logger
    locator.registerSingleton(ServiceTokens.Logger, new ConsoleLogger());
 
    // Register lazy singleton for repository (database connection deferred)
    locator.registerLazySingleton(
        ServiceTokens.UserRepository,
        () => new PostgresUserRepository(getDbConnection())
    );
 
    // Register transient email service (new instance each time)
    locator.registerTransient(
        ServiceTokens.EmailService,
        () => new SmtpEmailService(getSmtpConfig())
    );
}
 
// Usage in application code
class UserService {
    private logger: ILogger;
    private userRepo: IUserRepository;
    private emailService: IEmailService;
 
    constructor() {
        // Resolve dependencies from the locator
        const locator = TypedServiceLocator.getInstance();
        this.logger = locator.resolve(ServiceTokens.Logger);
        this.userRepo = locator.resolve(ServiceTokens.UserRepository);
        this.emailService = locator.resolve(ServiceTokens.EmailService);
    }
 
    async registerUser(email: string, name: string): Promise<User> {
        this.logger.log(`Registering user: ${email}`);
        
        const user = new User(email, name);
        await this.userRepo.save(user);
        await this.emailService.send(email, "Welcome!", "Thanks for registering");
        
        return user;
    }
}

This type-safe implementation provides compile-time verification that you're requesting services of the correct type. The ServiceIdentifier<T> pattern uses TypeScript's type inference to ensure that resolve() returns the correct type without casts.

Historical Context and Evolution

Service Locator emerged as a response to the chaos of unmanaged dependencies in early object-oriented systems. Before patterns like Service Locator and Dependency Injection, systems typically suffered from:

Direct instantiation: Classes created their dependencies directly using new, creating tight coupling
Global variables: Shared services stored in module-level or static variables
Spaghetti dependencies: No clear structure for how components obtained collaborators

Service Locator offered structure: a single, well-known location for service resolution. This was particularly influential in Java's J2EE (now Jakarta EE) ecosystem, where the JNDI (Java Naming and Directory Interface) served as a de facto Service Locator:

// Classic J2EE Service Locator pattern
Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/MyDatabase");

The pattern also appears in various forms across frameworks:

Service Locator Implementations Across Ecosystems
Platform/Framework	Service Locator Mechanism	Characteristics
Java J2EE/Jakarta EE	JNDI (Java Naming and Directory Interface)	Hierarchical naming, supports remote lookup
Android	getSystemService()	Built into Context class, type-safe in newer versions
Unity3D	ServiceLocator pattern, GameObject.Find()	Common in game development for cross-cutting services
.NET (older)	Common Service Locator library	Abstraction over various DI containers
Angular (partial)	Injector.get() direct calls	Though primarily DI, can be used as locator
Legacy enterprise apps	Custom registry patterns	Often evolved from Singleton collections

The shift to Dependency Injection:

The publication of Martin Fowler's influential article 'Inversion of Control Containers and the Dependency Injection Pattern' (2004) crystallized the distinction between Service Locator and Dependency Injection. Fowler described both as implementations of Inversion of Control (IoC), but highlighted their different characteristics.

The Java Spring Framework, emerging around the same time, heavily promoted constructor and setter injection, demonstrating that complex applications could be built without Service Locators. This shift accelerated as the software industry recognized the testing and maintainability benefits of injection over location.

Both Are Inversion of Control

Both Service Locator and Dependency Injection are forms of Inversion of Control (IoC)—the component doesn't control how its dependencies are created. The difference lies in how the dependency arrives: with a locator, the component pulls; with injection, something else pushes. This distinction has profound implications for testability and transparency.

Why Service Locator Was an Improvement

To understand Service Locator's appeal, we must compare it to what came before. Consider a system without any dependency management:

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
// Without any IoC - tight coupling everywhere
 
class OrderService {
    private inventory: InventoryService;
    private payment: PaymentProcessor;
    private notifier: EmailNotifier;
    private logger: Logger;
 
    constructor() {
        // Direct instantiation - OrderService knows everything
        // about how to create its dependencies
        this.inventory = new InventoryService(
            new PostgresInventoryRepository(
                new PostgresConnection("postgresql://prod:5432/inventory")
            )
        );
        
        this.payment = new StripePaymentProcessor(
            "sk_live_xxx",
            new HttpClient(),
            new ConsoleLogger()
        );
        
        this.notifier = new EmailNotifier(
            new SmtpClient("smtp.company.com", 587, "user", "pass")
        );
        
        this.logger = new ConsoleLogger();
    }
}
 
// Problems with this approach:
// 1. OrderService is coupled to CONCRETE implementations
// 2. Configuration (connection strings, API keys) is hardcoded
// 3. Cannot use different implementations in tests
// 4. Every class that needs these services duplicates this setup
// 5. Changes to dependencies require modifying all consumers

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
// With Service Locator - consumers are decoupled from construction
 
class OrderService {
    private inventory: IInventoryService;
    private payment: IPaymentProcessor;
    private notifier: INotificationService;
    private logger: ILogger;
 
    constructor() {
        // Resolve from locator - OrderService doesn't know
        // how these are created or configured
        const locator = ServiceLocator.getInstance();
        this.inventory = locator.resolve(ServiceTokens.Inventory);
        this.payment = locator.resolve(ServiceTokens.Payment);
        this.notifier = locator.resolve(ServiceTokens.Notifier);
        this.logger = locator.resolve(ServiceTokens.Logger);
    }
}
 
// Configuration is centralized in bootstrap
function bootstrap() {
    const locator = ServiceLocator.getInstance();
    
    // All construction logic in one place
    locator.registerSingleton(
        ServiceTokens.Logger,
        new ConsoleLogger()
    );
    
    locator.registerLazySingleton(
        ServiceTokens.Inventory,
        () => new InventoryService(
            new PostgresInventoryRepository(
                new PostgresConnection(config.inventoryDbUrl)
            )
        )
    );
    
    // Easy to swap for different environments
    if (config.environment === "test") {
        locator.registerSingleton(
            ServiceTokens.Payment,
            new MockPaymentProcessor()
        );
    } else {
        locator.registerSingleton(
            ServiceTokens.Payment,
            new StripePaymentProcessor(config.stripeKey)
        );
    }
}

Improvements Service Locator provides over direct instantiation:

Service Locator Benefits vs Raw Dependencies

•Decouples consumers from concrete types — Components depend on interfaces, not implementations. You can swap PostgreSQL for MongoDB without changing consumer code.
•Centralizes configuration — Connection strings, API keys, and environment-specific settings are managed in one place during bootstrap.
•Enables environment-specific instantiation — Use mock implementations for testing, staging configurations for QA, production implementations for deployment.
•Supports lifecycle management — The locator can manage singleton instances, ensuring shared services aren't created multiple times.
•Reduces boilerplate — Consumers don't repeat construction logic; they simply request what they need.

An Improvement, But Not the Best

While Service Locator significantly improves upon raw dependency creation, it introduces its own problems—problems that Dependency Injection solves more elegantly. We'll examine these limitations in the next pages, but it's important to recognize that Service Locator was a genuine step forward in its time.

Anatomy of Service Resolution

Let's examine precisely what happens when a component resolves a service from a locator. Understanding this flow reveals both the flexibility and the problems inherent in the 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
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
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
class DetailedServiceLocator {
    private services: Map<symbol, ServiceDescriptor<any>> = new Map();
    private resolutionStack: symbol[] = []; // Track for circular dependency detection
 
    resolve<T>(identifier: ServiceIdentifier<T>): T {
        // 1. Check for circular dependencies
        if (this.resolutionStack.includes(identifier.id)) {
            const cycle = [...this.resolutionStack, identifier.id]
                .map(s => s.toString())
                .join(' -> ');
            throw new CircularDependencyError(
                `Circular dependency detected: ${cycle}`
            );
        }
 
        // 2. Lookup the service descriptor
        const descriptor = this.services.get(identifier.id);
        if (!descriptor) {
            throw new ServiceNotRegisteredError(
                `No service registered for: ${identifier.id.toString()}`
            );
        }
 
        // 3. For singletons with existing instance, return immediately
        if (descriptor.lifecycle === 'singleton' && descriptor.instance) {
            return descriptor.instance;
        }
 
        // 4. Push to resolution stack (for circular dependency detection)
        this.resolutionStack.push(identifier.id);
 
        try {
            // 5. Create the instance
            let instance: T;
            
            if (descriptor.factory) {
                // Factory-based creation
                instance = descriptor.factory(this); // Pass locator for nested resolution
            } else if (descriptor.constructor) {
                // Constructor-based creation with resolved dependencies
                const deps = descriptor.dependencies.map(
                    dep => this.resolve(dep)
                );
                instance = new descriptor.constructor(...deps);
            } else {
                throw new InvalidServiceDescriptorError(
                    `No factory or constructor for service`
                );
            }
 
            // 6. Store singleton instance
            if (descriptor.lifecycle === 'singleton') {
                descriptor.instance = instance;
            }
 
            return instance;
 
        } finally {
            // 7. Pop from resolution stack
            this.resolutionStack.pop();
        }
    }
}
 
// Example: A service that resolves its own dependencies from the locator
class NotificationOrchestrator {
    private emailService: IEmailService;
    private smsService: ISmsService;
    private pushService: IPushNotificationService;
    private logger: ILogger;
 
    constructor() {
        const locator = DetailedServiceLocator.getInstance();
        
        // Each resolve() triggers the full resolution flow above
        // If EmailService also resolves dependencies, they chain
        this.emailService = locator.resolve(ServiceTokens.Email);
        this.smsService = locator.resolve(ServiceTokens.SMS);
        this.pushService = locator.resolve(ServiceTokens.Push);
        this.logger = locator.resolve(ServiceTokens.Logger);
    }
 
    async notifyUser(userId: string, message: string, channels: Channel[]) {
        this.logger.log(`Notifying ${userId} on channels: ${channels}`);
        
        const promises = channels.map(channel => {
            switch (channel) {
                case Channel.Email: return this.emailService.send(userId, message);
                case Channel.SMS: return this.smsService.send(userId, message);
                case Channel.Push: return this.pushService.send(userId, message);
            }
        });
 
        await Promise.all(promises);
    }
}

Critical observation: Resolution happens at runtime

Notice that all resolution occurs during object construction—at runtime. The compiler cannot verify:

That the required services are registered
That registration happens before resolution
That the resolution order won't cause issues
That there are no circular dependencies

This runtime-only verification is a fundamental characteristic of Service Locator. It means errors that could be caught at compile time with Dependency Injection only manifest when the code actually executes—potentially in production.

Common Registration Patterns

How services get registered varies significantly across implementations. Each approach has tradeoffs around discoverability, compile-time safety, and flexibility.

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
// All registrations in a single configuration function
// Pros: Explicit, easy to find, clear startup order
// Cons: Becomes large, easy to forget registrations
 
function configureAllServices(locator: ServiceLocator) {
    // Infrastructure
    locator.register(ServiceTokens.Logger, new ConsoleLogger());
    locator.register(ServiceTokens.Config, new EnvironmentConfig());
    
    // Data access
    const config = locator.resolve(ServiceTokens.Config);
    locator.register(
        ServiceTokens.Database,
        new PostgresConnection(config.databaseUrl)
    );
    
    // Repositories
    locator.register(
        ServiceTokens.UserRepo,
        new PostgresUserRepository(locator.resolve(ServiceTokens.Database))
    );
    locator.register(
        ServiceTokens.OrderRepo,
        new PostgresOrderRepository(locator.resolve(ServiceTokens.Database))
    );
    
    // Services
    locator.register(
        ServiceTokens.UserService,
        new UserService() // Will resolve its own deps from locator
    );
    locator.register(
        ServiceTokens.OrderService,
        new 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
49
// Break registration into logical modules
// Pros: Organized, teams can own modules
// Cons: Registration order can be tricky
 
interface IServiceInstaller {
    install(locator: ServiceLocator): void;
}
 
class InfrastructureInstaller implements IServiceInstaller {
    install(locator: ServiceLocator): void {
        locator.register(ServiceTokens.Logger, new ConsoleLogger());
        locator.register(ServiceTokens.Config, new EnvironmentConfig());
        locator.register(ServiceTokens.HttpClient, new FetchHttpClient());
    }
}
 
class DataAccessInstaller implements IServiceInstaller {
    install(locator: ServiceLocator): void {
        const config = locator.resolve(ServiceTokens.Config);
        locator.register(
            ServiceTokens.Database,
            new PostgresConnection(config.databaseUrl)
        );
    }
}
 
class UserModuleInstaller implements IServiceInstaller {
    install(locator: ServiceLocator): void {
        locator.register(ServiceTokens.UserRepo, new PostgresUserRepository());
        locator.register(ServiceTokens.UserService, new UserService());
        locator.register(ServiceTokens.AuthService, new JwtAuthService());
    }
}
 
// Bootstrap with ordered installation
function bootstrap() {
    const locator = ServiceLocator.getInstance();
    const installers: IServiceInstaller[] = [
        new InfrastructureInstaller(), // Must be first
        new DataAccessInstaller(),
        new UserModuleInstaller(),
        new OrderModuleInstaller(),
        // ... more installers
    ];
 
    for (const installer of installers) {
        installer.install(locator);
    }
}

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
// Use decorators to mark classes for registration
// Pros: Registration close to implementation
// Cons: Magic behavior, requires reflection/scanning
 
// Decorator to mark a class as a service
function Service(token: ServiceIdentifier<any>) {
    return function<T extends new (...args: any[]) => any>(constructor: T) {
        // Store metadata for later scanning
        Reflect.defineMetadata('service:token', token, constructor);
        return constructor;
    };
}
 
function Singleton(token: ServiceIdentifier<any>) {
    return function<T extends new (...args: any[]) => any>(constructor: T) {
        Reflect.defineMetadata('service:token', token, constructor);
        Reflect.defineMetadata('service:lifecycle', 'singleton', constructor);
        return constructor;
    };
}
 
// Apply decorators to service classes
@Singleton(ServiceTokens.Logger)
class ConsoleLogger implements ILogger {
    log(message: string): void {
        console.log(`[${new Date().toISOString()}] ${message}`);
    }
}
 
@Service(ServiceTokens.UserService)
class UserService {
    // ...
}
 
// Auto-registration scans for decorated classes
function autoRegisterServices(locator: ServiceLocator) {
    // Scan all loaded classes (implementation varies by runtime)
    const serviceClasses = scanForDecoratedClasses('service:token');
    
    for (const cls of serviceClasses) {
        const token = Reflect.getMetadata('service:token', cls);
        const lifecycle = Reflect.getMetadata('service:lifecycle', cls) || 'transient';
        
        if (lifecycle === 'singleton') {
            locator.registerSingleton(token, new cls());
        } else {
            locator.registerTransient(token, () => new cls());
        }
    }
}

Pull vs Push: The Fundamental Distinction

The deepest distinction between Service Locator and Dependency Injection is the direction of dependency flow:

Service Locator: PULL — The component reaches out and pulls its dependencies from a global registry
Dependency Injection: PUSH — Something external pushes dependencies into the component

This distinction has profound implications for how code is structured, tested, and reasoned about.

PULL: Service Locator

•Component knows about the locator
•Component decides when to resolve
•Dependencies are not visible in constructor
•Requires global/static access to locator
•Resolution happens inside the class
•Testing requires setting up the global locator

PUSH: Dependency Injection

•Component doesn't know about container
•External code controls when to inject
•Dependencies explicit in constructor
•No global state required
•Resolution happens outside the class
•Testing uses direct instantiation

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
// === SERVICE LOCATOR (PULL) ===
class UserController_Locator {
    private userService: IUserService;
    private authService: IAuthService;
 
    constructor() {
        // This class KNOWS about ServiceLocator
        // This class PULLS its dependencies
        const locator = ServiceLocator.getInstance();
        this.userService = locator.resolve(ServiceTokens.UserService);
        this.authService = locator.resolve(ServiceTokens.AuthService);
    }
 
    async getUser(request: Request): Promise<Response> {
        await this.authService.validateToken(request.token);
        const user = await this.userService.findById(request.userId);
        return new Response(user);
    }
}
 
// === DEPENDENCY INJECTION (PUSH) ===
class UserController_DI {
    // Dependencies declared explicitly - visible in class signature
    constructor(
        private readonly userService: IUserService,
        private readonly authService: IAuthService
    ) {
        // No reference to any container or locator
        // Dependencies are PUSHED in from outside
    }
 
    async getUser(request: Request): Promise<Response> {
        await this.authService.validateToken(request.token);
        const user = await this.userService.findById(request.userId);
        return new Response(user);
    }
}
 
// Testing difference is dramatic:
 
// Locator version - must set up global state
test("UserController_Locator gets user", async () => {
    // Setup: Configure the GLOBAL locator
    const locator = ServiceLocator.getInstance();
    locator.clear();
    locator.register(ServiceTokens.UserService, mockUserService);
    locator.register(ServiceTokens.AuthService, mockAuthService);
 
    // Now we can test
    const controller = new UserController_Locator();
    const result = await controller.getUser(request);
    
    // Teardown: Clean up global state
    locator.clear();
});
 
// DI version - just pass dependencies directly
test("UserController_DI gets user", async () => {
    // No global state to manage
    const controller = new UserController_DI(mockUserService, mockAuthService);
    const result = await controller.getUser(request);
    // No teardown needed
});

The Visibility Problem

With Service Locator, you cannot know what a class needs just by looking at its constructor. The dependencies are hidden inside the implementation—they're invisible until you read the code. With Dependency Injection, the constructor signature is a complete contract: 'Give me these things, and I will work.'

Summary: The Service Locator Pattern

We've established a thorough understanding of the Service Locator pattern—its mechanics, variations, and historical role in software architecture. Let's consolidate the key points:

Key Takeaways

•Service Locator is a centralized registry — Components query this global registry to obtain their dependencies at runtime.
•It's a pull-based approach — Unlike Dependency Injection where dependencies are pushed in, Service Locator has components pull what they need.
•It was a genuine improvement — Compared to raw dependency creation, Service Locator provided decoupling, centralized configuration, and swappable implementations.
•Type-safe implementations exist — Modern implementations use types or symbols instead of strings, providing compile-time safety for the resolution call itself.
•Resolution is runtime-only — Whether services are registered correctly can only be verified when code executes, not at compile time.
•Dependencies are hidden — Looking at a class's public interface doesn't reveal what it depends on—you must read the implementation.

What's next:

Having established what Service Locator is and how it works, we'll now examine why it's considered an anti-pattern in modern software development. The next page explores the specific problems Service Locator creates—problems that become increasingly severe as codebases grow and teams scale.

Page Complete

You now understand the Service Locator pattern in depth—its mechanics, implementation variations, and historical context. This foundation prepares you to critically evaluate its shortcomings and understand why Dependency Injection became the preferred approach for managing object dependencies.