Service Locator — pattern mohiyati, markaziy reyestr va DI

Service Locator nima: pattern mohiyati va tuzilishi

Service Locator — xizmatlarni yaratish va taqdim etishni markazlashtiradigan pattern. Asosda xizmatlar reyestrini (Registry) o'z ichiga olgan Singleton sinfi (Locator) yotadi: kalit xizmatning turi (yoki identifikatori), qiymat esa aniq implementatsiya bo'lgan lug'at. Mijoz kodi ServiceLocator.resolve(ServiceProtocol.self) chaqiradi va tayyor instansiyani oladi. Pattern xizmat qanday yaratilishini belgilamaydi — fabrika, DI konteyner yoki lokator ichida new.

Pattern tuzilishi — Registry ([String: Any] tipidagi reyestr), Locator (register va resolve bilan statik sinf), Service (ro'yxatdan o'tkaziladigan xizmat). Reyestr fabrikalarni (obyekt yaratish uchun closure/lambda) yoki tayyor instansiyalarni saqlashi mumkin. Lokator global (ilova uchun bitta) yoki doiraviy (feature/modul bo'yicha) bo'lishi mumkin. Xizmatni hal qilish — lug'atda tur bo'yicha qidirish. Swift va Kotlin metatiplar orqali turni kalit sifatida ishlatadi: ObjectIdentifier(ServiceProtocol.self).

Pattern tarixi — Service Locator Java Patterns (1998) kitobida va keyinroq Core J2EE Patterns (2001) kitobida tasvirlangan. Martin Fowler 2004-yilgi maqolasida Service Locator-ni DI bilan solishtirib, Service Locator „soddaroq muqobil, ammo test uchun yomonroq“ ekanligini ta'kidlaydi. Mobil ishlanmada Service Locator Dagger va Swinject paydo bo'lishidan oldin dastlabki Android loyihalarida va iOS ilovalarida ishlatilgan. Hozir pattern ko'proq legacy loyihalarda va prototiplarda uchraydi.

Swift-da Service Locator: global xizmatlar reyestri

Swift-da Service Locator — statik xususiyatlar va thread-safe lug'at orqali amalga oshirish. Kalit sifatida ObjectIdentifier(Protocol.self) va qiymat sifatida fabrikalar (()->Any) bilan reyestr ishlatiladi. Kechikuvchi initsializatsiya (lazy var) — standart amaliyot: xizmat birinchi so'rovda yaratiladi. Swift resolve vaqtida turni aniq konvertatsiya qilishni talab qiladi: guard let service = locator.resolve(ServiceProtocol.self) else { return }.

final class ServiceLocator {
    static let shared = ServiceLocator()
    private var registry: [ObjectIdentifier: Any] = [:]
    private let lock = NSLock()

    func register<T>(_ type: T.Type, factory: @escaping () -> T) {
        lock.lock()
        registry[ObjectIdentifier(type)] = factory
        lock.unlock()
    }

    func resolve<T>(_ type: T.Type) -> T {
        lock.lock()
        defer { lock.unlock() }
        guard let factory = registry[ObjectIdentifier(type)] as? () -> T else {
            fatalError("Service \(type) not registered")
        }
        return factory()
    }

    func reset() {
        lock.lock()
        registry.removeAll()
        lock.unlock()
    }
}

// Ro'yxatdan o'tkazish
ServiceLocator.shared.register(NetworkServiceProtocol.self) { NetworkService() }

// Foydalanish
let network = ServiceLocator.shared.resolve(NetworkServiceProtocol.self)

Doirani boshqarish — lokator fabrikalarni (transient — har safar yangi obyekt) yoki tayyor instansiyalarni (singleton) saqlashi mumkin. Fabrikalar uchun har bir resolve chaqiruvida bajariladigan closure ro'yxatdan o'tkaziladi. Singleton uchun — yaratilgan instansiyani tutib qoladigan closure. Doira qo'shish: .transient, .singleton, .weak (zaif havola — obyekt kimdir havolani ushlab turguncha yashaydi). Weak doirasi UIKit ViewController uchun qulay bo'lib, pop/dismiss vaqtida xotira oqishini oldini oladi.

Kotlin-da Service Locator: kechikuvchi ro'yxatdan o'tkazish

Kotlin-da Service Locator — tip xavfsizligi uchun reified inline funksiyalari bilan object (Singleton) orqali ixcham amalga oshirish. Kotlin qisqa lokator yaratishga imkon beradi: val service by locator<ServiceProtocol>() delegat bilan, bu kodni tozaroq qiladi. Reified generics (<reified T>) ObjectIdentifier o'rnini bosadi — tip generikdan olinadi. Kotlin lokatorlari ko'pincha aniq blokirovkalarsiz thread-safe bo'lish uchun ConcurrentHashMap ishlatadi.

object ServiceLocator {
    private val registry = ConcurrentHashMap<Class<*>, () -> Any>()

    inline fun <reified T: Any> register(noinline factory: () -> T) {
        registry[T::class.java] = factory
    }

    @Suppress("UNCHECKED_CAST")
    inline fun <reified T: Any> resolve(): T {
        val factory = registry[T::class.java]
            ?: throw IllegalStateException("Service ${T::class.simpleName} not registered")
        return factory() as T
    }

    fun clear() {
        registry.clear()
    }
}

// Ro'yxatdan o'tkazish
ServiceLocator.register<ApiService> { RetrofitApiService() }

// Sinfda foydalanish
class UserRepository {
    private val api: ApiService = ServiceLocator.resolve()
    private val db: Database = ServiceLocator.resolve()
}

// Kechikuvchi hal qilish uchun delegat
class LocatorDelegate<reified T: Any> : Lazy<T> {
    override val value: T get() = ServiceLocator.<T>resolve()
    override fun isInitialized(): Boolean = true
}

inline fun <reified T: Any> locator(): Lazy<T> = LocatorDelegate()
// Foydalanish: val api by locator()

Android-da Service Locator — Dagger paydo bo'lishidan oldin eski loyihalarda uchraydi. Jetpack Hilt va Koin Android hamjamiyatida Service Locator-ni siqib chiqardi. Biroq, lokator modul testlari uchun dolzarb bo'lib qolmoqda: Hilt-siz mock-xizmatlar bilan oddiy ServiceLocator taqlidi. Plyus: testlar uchun Dagger kompilyatsiyasini kutish shart emas. Minus: agar testda lokatorni almashtirishni unutsangiz, testlar ishlab chiqarish xizmatlaridan foydalanadi.

Service Locator vs DI: solishtirish va qachon nima tanlash

Bog'liqliklarning aniqliligi — asosiy farq. DI bog'liqliklarni aniq e'lon qiladi: init(service: ServiceProtocol) — har qanday IDE sinfning bog'liqliklarini ko'rsatadi. Service Locator ularni yashiradi: dependencies = ServiceLocator.resolve() — metod ichida yashirin. DI bilan sinfning barcha bog'liqliklarini darhol ko'rish mumkin, Service Locator bilan sinfning butun tanasini o'qish kerak. Bu Service Locator kodini kamroq bashorat qilinadigan qiladi: reyestrda o'zgarish lokatordan foydalanadigan istalgan sinfni buzishi mumkin.

Service Locator qachon oqlanadi — prototiplar va MVP (sozlamasiz tez boshlash). DI ramkasini qo'shib bo'lmaydigan legacy loyihalar (murakkab kompilyatsiya, linter cheklovlari). Asbobiy kutubxonalar (loglash, crash-reporting) — ular baribir global. 3 dasturchidan iborat jamoasi bo'lgan ishlab chiqarish ilovalari uchun DI tavsiya etiladi: aniq bog'liqliklar refaktoringdagi xatolar sonini kamaytiradi va yangi dasturchilarning loyihaga kirishini osonlashtiradi.

Service Locator muammolari va muqobillar

Yashirin bog'liqliklar — metod ichida ServiceLocator.resolve() ishlatadigan sinfni statik tahlil qilib bo'lmaydi. IDE bog'liqliklarni ko'rsatmaydi, kompilyator xizmat ro'yxatdan o'tganligini tekshirmaydi. „Service not registered“ xatosi faqat ish vaqtida yuz beradi. Refaktoring xavfli bo'ladi: reyestrdan xizmatni olib tashlash ilovadagi istalgan sinfni buzishi mumkin. DI bu muammoni kompilyatsiya vaqti tekshiruvlari (Dagger) yoki aniq konstruktorlar orqali hal qiladi.

Test muammosi — har bir test barcha bog'liqliklar bilan ServiceLocator.shared-ni sozlashi kerak. Testdan so'ng — holatni tiklash (reset()). Testlarning parallel bajarilishida ServiceLocator.shared-ning global holati race condition-ga olib keladi: bir test mock ro'yxatdan o'tkazadi, boshqasi — boshqaning mock-ni oladi. Yechim: doiraviy lokatorlar (test boshiga bitta) yoki ThreadLocal. DI bu muammoni tubdan hal qiladi: har bir test o'z instansiyasini mock-bog'liqliklar bilan yaratadi.

// Service Locator test muammosi
class LoginViewModelTests: XCTestCase {
    override func setUp() {
        super.setUp()
        // Test uchun global reyestrni sozlash
        ServiceLocator.shared.register(AuthServiceProtocol.self) { MockAuthService() }
    }

    override func tearDown() {
        ServiceLocator.shared.reset()
        super.tearDown()
    }

    func testLogin() {
        let viewModel = LoginViewModel() // ichida ServiceLocator ishlatadi
        // test...
    }
}

Service Locator muqobillari — DI (Dagger, Swinject), Factory Method, Ambient Context. Factory Method — global holatsiz oddiy pattern: fabrika sinfi xizmatlarni yaratadi va konstruktor orqali uzatiladi. Ambient Context — cross-cutting concerns (loglash, autentifikatsiya) uchun thread-safe muqobil. Eng yaxshi muqobil — DI ramkasisiz qo'lda Constructor Injection: fabrikada bog'liqliklarni aniq yaratish va konstruktor orqali uzatish Dagger/Swinject sozlash murakkabligisiz DI ning ravshanligini beradi.