7a:T405,// A simple Service Locator implementation class ServiceLocator { private static instance: ServiceLocator; private services: Map = 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(key: string, service: T): void { this.services.set(key, service); } // Retrieve a service by key resolve(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(); } }7b:Ta71,// Service identifier using symbols for type safety interface ServiceIdentifier { readonly id: symbol; readonly _type?: T; // Phantom type for type inference } // Factory function type type ServiceFactory = () => T; // Registration record interface ServiceRecord { factory?: ServiceFactory; instance?: T; singleton: boolean; } class TypedServiceLocator { private static instance: TypedServiceLocator; private services: Map> = 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(name: string): ServiceIdentifier { return { id: Symbol(name) }; } // Register a singleton instance registerSingleton( identifier: ServiceIdentifier, instance: T ): void { this.services.set(identifier.id, { instance, singleton: true }); } // Register a factory for transient instances registerTransient( identifier: ServiceIdentifier, factory: ServiceFactory ): void { this.services.set(identifier.id, { factory, singleton: false }); } // Register a factory that creates a singleton on first resolve registerLazySingleton( identifier: ServiceIdentifier, factory: ServiceFactory ): void { this.services.set(identifier.id, { factory, singleton: true }); } // Resolve a service resolve(identifier: ServiceIdentifier): 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(identifier: ServiceIdentifier): T | undefined { try { return this.resolve(identifier); } catch { return undefined; } } }7c:T864,// Define service interfaces interface ILogger { log(message: string): void; error(message: string): void; } interface IUserRepository { findById(id: string): Promise; save(user: User): Promise; } interface IEmailService { send(to: string, subject: string, body: string): Promise; } // Create identifiers (typically in a central file) const ServiceTokens = { Logger: TypedServiceLocator.createIdentifier("Logger"), UserRepository: TypedServiceLocator.createIdentifier("UserRepository"), EmailService: TypedServiceLocator.createIdentifier("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 { 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; } }7d:T4c8,// 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 consumers7e:T624,// 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) ); } }7f:Te05,class DetailedServiceLocator { private services: Map> = new Map(); private resolutionStack: symbol[] = []; // Track for circular dependency detection resolve(identifier: ServiceIdentifier): 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); } }80:T45d,// 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() ); }81:T654,// 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); } }82:T6b9,// 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) { return function any>(constructor: T) { // Store metadata for later scanning Reflect.defineMetadata('service:token', token, constructor); return constructor; }; } function Singleton(token: ServiceIdentifier) { return function 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()); } } }83:T87f,// === 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 { 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 { 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 });72:{"json":{"id":"seed_102d7452091c810e229ec69a3e4317d8","slug":"service-locator-vs-dependency-injection","category":"System Design (LLD)","topic":"Service Locator vs Dependency Injection","title":"Service Locator vs Dependency Injection","description":"Understand the Service Locator pattern, why it's often considered an anti-pattern, and when it might still be appropriate. Learn to recognize hidden dependency problems and make informed decisions about dependency resolution strategies.","difficulty":"INTERMEDIATE","estimatedMinutes":55,"pages":[{"id":"seed_dce6f61c8bda936fa40bde4683622659","title":"Service Locator Pattern","order":0,"content":[{"id":"opening-hook","title":"The Global Registry Approach","content":[{"data":{"content":"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.\n\nUnderstanding 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."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"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.","variant":"info"},"type":"callout"}]},{"id":"definition-and-mechanics","title":"What Is a Service Locator?","content":[{"data":{"content":"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.\n\nThe fundamental mechanics are straightforward:\n\n1. **Registration**: Services are registered with the locator, typically during application startup\n2. **Resolution**: Components query the locator to retrieve registered services\n3. **Abstraction**: The locator typically returns interfaces, allowing implementations to vary\n\nConceptually, 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."},"type":"text"},{"data":{"code":"$7a","title":"Basic Service Locator Structure","language":"typescript"},"type":"code"},{"data":{"content":"This basic implementation demonstrates the pattern's core mechanics. In practice, Service Locators often include additional features:\n\n- **Lifetime management**: Creating new instances (transient) vs returning singletons\n- **Lazy initialization**: Deferring service creation until first resolution\n- **Type-safe registration**: Using types or interfaces as keys instead of strings\n- **Hierarchical scopes**: Child locators that inherit from parents\n- **Factory registration**: Registering factory functions instead of instances"},"type":"text"},{"data":{"icon":"Info","title":"The Singleton Connection","content":"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.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"type-safe-implementation","title":"Type-Safe Service Locator Implementations","content":[{"data":{"content":"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:"},"type":"text"},{"data":{"code":"$7b","title":"Type-Safe Service Locator with Factory Support","language":"typescript"},"type":"code"},{"data":{"code":"$7c","title":"Using the Type-Safe Service Locator","language":"typescript"},"type":"code"},{"data":{"content":"This type-safe implementation provides compile-time verification that you're requesting services of the correct type. The `ServiceIdentifier` pattern uses TypeScript's type inference to ensure that `resolve()` returns the correct type without casts."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"historical-context","title":"Historical Context and Evolution","content":[{"data":{"content":"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:\n\n- **Direct instantiation**: Classes created their dependencies directly using `new`, creating tight coupling\n- **Global variables**: Shared services stored in module-level or static variables\n- **Spaghetti dependencies**: No clear structure for how components obtained collaborators\n\nService 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:\n\n```java\n// Classic J2EE Service Locator pattern\nContext ctx = new InitialContext();\nDataSource ds = (DataSource) ctx.lookup(\"java:comp/env/jdbc/MyDatabase\");\n```\n\nThe pattern also appears in various forms across frameworks:"},"type":"text"},{"data":{"rows":[["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"]],"caption":"Service Locator Implementations Across Ecosystems","headers":["Platform/Framework","Service Locator Mechanism","Characteristics"]},"type":"table"},{"data":{"content":"**The shift to Dependency Injection:**\n\nThe 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.\n\nThe 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."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Both Are Inversion of Control","content":"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.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"vs-direct-instantiation","title":"Why Service Locator Was an Improvement","content":[{"data":{"content":"To understand Service Locator's appeal, we must compare it to what came before. Consider a system without any dependency management:"},"type":"text"},{"data":{"code":"$7d","title":"The Problem: Direct Instantiation and Tight Coupling","language":"typescript"},"type":"code"},{"data":{"code":"$7e","title":"The Improvement: Service Locator Decouples Consumers","language":"typescript"},"type":"code"},{"data":{"content":"**Improvements Service Locator provides over direct instantiation:**"},"type":"text"},{"data":{"items":["**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."],"title":{"icon":"CheckCircle","text":"Service Locator Benefits vs Raw Dependencies","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"AlertTriangle","title":"An Improvement, But Not the Best","content":"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.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"anatomy-of-resolution","title":"Anatomy of Service Resolution","content":[{"data":{"content":"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."},"type":"text"},{"data":{"code":"$7f","title":"Service Resolution Flow with Error Handling","language":"typescript"},"type":"code"},{"data":{"content":"**Critical observation: Resolution happens at runtime**\n\nNotice that all resolution occurs during object construction—at runtime. The compiler cannot verify:\n\n1. That the required services are registered\n2. That registration happens before resolution\n3. That the resolution order won't cause issues\n4. That there are no circular dependencies\n\nThis 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."},"type":"text"}],"titleType":"number","titleNumber":5},{"id":"registration-patterns","title":"Common Registration Patterns","content":[{"data":{"content":"How services get registered varies significantly across implementations. Each approach has tradeoffs around discoverability, compile-time safety, and flexibility."},"type":"text"},{"data":{"code":"$80","title":"Manual Centralized Registration","language":"typescript"},"type":"code"},{"data":{"code":"$81","title":"Modular Registration with Installers","language":"typescript"},"type":"code"},{"data":{"code":"$82","title":"Decorator-Based Auto-Registration","language":"typescript"},"type":"code"}],"titleType":"number","titleNumber":6},{"id":"pull-vs-push","title":"Pull vs Push: The Fundamental Distinction","content":[{"data":{"content":"The deepest distinction between Service Locator and Dependency Injection is the direction of dependency flow:\n\n- **Service Locator: PULL** — The component reaches out and pulls its dependencies from a global registry\n- **Dependency Injection: PUSH** — Something external pushes dependencies into the component\n\nThis distinction has profound implications for how code is structured, tested, and reasoned about."},"type":"text"},{"data":{"left":[{"data":{"items":["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"],"title":{"icon":"ArrowDownCircle","text":"PULL: Service Locator","type":"icon","color":"accent","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["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"],"title":{"icon":"ArrowUpCircle","text":"PUSH: Dependency Injection","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"code":"$83","title":"Side-by-Side Comparison","language":"typescript"},"type":"code"},{"data":{"icon":"Eye","title":"The Visibility Problem","content":"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.'","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary-path-forward","title":"Summary: The Service Locator Pattern","content":[{"data":{"content":"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:"},"type":"text"},{"data":{"type":"ordered","items":["**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."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nHaving 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."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"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.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_1a2abf58041e673ebdeef8068821408b","title":"Why Service Locator Is Often an Anti-Pattern","order":1,"content":null,"isLocked":true},{"id":"seed_7783f83aa9de332e0d2914617afc46d9","title":"Hidden Dependencies Problem","order":2,"content":null,"isLocked":true},{"id":"seed_4462d2e5d0922c4e244becf55fb10295","title":"When Service Locator Is Acceptable","order":3,"content":null,"isLocked":true}]}}