Service Locator — پیٹرن کا جوہر، مرکزی رجسٹری اور DI

Service Locator کیا ہے: پیٹرن کا جوہر اور ساخت

Service Locator ایک پیٹرن ہے جو خدمات کی تخلیق اور فراہمی کو مرکزی بناتا ہے۔ یہ ایک Singleton کلاس (Locator) پر مبنی ہے جس میں خدمات کی ایک رجسٹری ہوتی ہے: ایک لغت جہاں کلید سروس کی قسم (یا شناخت کنندہ) ہے اور قدر ٹھوس نفاذ ہے۔ کلائنٹ کوڈ ServiceLocator.resolve(ServiceProtocol.self) کو کال کرتا ہے اور ایک تیار مثال حاصل کرتا ہے۔ پیٹرن یہ طے نہیں کرتا کہ سروس کیسے بنائی جاتی ہے — فیکٹری، DI کنٹینر یا لوکیٹر کے اندر new۔

پیٹرن کی ساخت — رجسٹری ([String: Any] قسم کی لغت)، لوکیٹر (register اور resolve کے ساتھ جامد کلاس)، سروس (رجسٹر کی جا رہی سروس)۔ رجسٹری فیکٹریوں (آبجیکٹ بنانے کے لئے closures/lambdas) یا تیار مثالوں کو ذخیرہ کر سکتی ہے۔ لوکیٹر عالمی (ایک فی ایپلیکیشن) یا دائرہ کار والا (فی فیچر/ماڈیول) ہو سکتا ہے۔ سروس کا حل قسم کے لحاظ سے لغت میں تلاش ہے۔ Swift اور Kotlin میٹا ٹائپس کے ذریعے قسم کو کلید کے طور پر استعمال کرتے ہیں: ObjectIdentifier(ServiceProtocol.self)۔

پیٹرن کی تاریخ — Service Locator کو Java Patterns (1998) کتاب میں اور بعد میں Core J2EE Patterns (2001) میں بیان کیا گیا۔ مارٹن فاؤلر کے 2004 کے مضمون میں Service Locator کا DI سے موازنہ کیا گیا ہے، جس میں بتایا گیا ہے کہ Service Locator "ایک آسان متبادل ہے، لیکن جانچ کے لئے برا ہے۔" موبائل ڈویلپمنٹ میں، Dagger اور Swinject کے آنے سے پہلے ابتدائی Android منصوبوں اور iOS ایپس میں Service Locator استعمال ہوتا تھا۔ اب پیٹرن زیادہ تر وراثتی منصوبوں اور پروٹوٹائپس میں پایا جاتا ہے۔

Swift میں Service Locator: عالمی سروس رجسٹری

Swift میں Service Locator — جامد خصوصیات اور تھریڈ سیف لغت کے ذریعے نفاذ۔ ObjectIdentifier(Protocol.self) کو کلید اور فیکٹریوں (() -> Any) کو قدروں کے طور پر استعمال کرنے والی رجسٹری استعمال ہوتی ہے۔ سست ابتدا (lazy var) معیاری عمل ہے: سروس پہلی درخواست پر بنائی جاتی ہے۔ Swift کو resolve کے دوران واضح قسم کی تبدیلی کی ضرورت ہوتی ہے: 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()
    }
}

// رجسٹریشن
ServiceLocator.shared.register(NetworkServiceProtocol.self) { NetworkService() }

// استعمال
let network = ServiceLocator.shared.resolve(NetworkServiceProtocol.self)

دائرہ کار کا انتظام — لوکیٹر فیکٹریوں (transient — ہر بار نیا آبجیکٹ) یا تیار مثالوں (singleton) کو ذخیرہ کر سکتا ہے۔ فیکٹریوں کے لئے، ایک closure رجسٹر کیا جاتا ہے جو ہر resolve پر کال ہوتا ہے۔ Singleton کے لئے، ایک closure بنائی گئی مثال کو کیپچر کرتا ہے۔ دائرہ کار شامل کرنا: .transient، .singleton، .weak (کمزور حوالہ — آبجیکٹ اس وقت تک زندہ رہتا ہے جب تک کوئی حوالہ رکھتا ہے)۔ UIKit UIViewControllers کے لئے pop/dismiss پر رساؤ سے بچنے کے لئے Weak دائرہ کار آسان ہے۔

Kotlin میں Service Locator: سست رجسٹریشن

Kotlin میں Service Locator — قسم کی حفاظت کے لئے inline reified افعال کے ساتھ object (Singleton) کے ذریعے ایک کمپیکٹ نفاذ۔ Kotlin ایک مندوب کے ساتھ ایک مختصر لوکیٹر کی اجازت دیتا ہے: val service by locator()، کوڈ کو صاف ستھرا بناتا ہے۔ Reified generics () ObjectIdentifier کی جگہ لیتے ہیں — قسم generic سے حاصل ہوتی ہے۔ Kotlin لوکیٹر اکثر واضح تالے کے بغیر تھریڈ سیفٹی کے لئے ConcurrentHashMap استعمال کرتے ہیں۔

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()
    }
}

// رجسٹریشن
ServiceLocator.register<ApiService> { RetrofitApiService() }

// کلاس میں استعمال
class UserRepository {
    private val api: ApiService = ServiceLocator.resolve()
    private val db: Database = ServiceLocator.resolve()
}

// سست حل کے لئے مندوب
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()
// استعمال: val api by locator()

Android میں Service Locator — Dagger سے پہلے پرانے منصوبوں میں پایا جاتا ہے۔ Jetpack Hilt اور Koin نے Android کمیونٹی میں Service Locator کی جگہ لے لی ہے۔ تاہم، لوکیٹر یونٹ ٹیسٹ کے لئے متعلقہ رہتا ہے: Hilt کے بغیر mock خدمات کے ساتھ ایک سادہ ServiceLocator سٹب۔ فائدہ: ٹیسٹوں کے لئے Dagger کی compilation کا انتظار کرنے کی ضرورت نہیں۔ نقصان: اگر آپ ٹیسٹ میں لوکیٹر کو اوور رائڈ کرنا بھول جاتے ہیں، تو ٹیسٹ پروڈکشن خدمات استعمال کرتے ہیں۔

Service Locator vs DI: موازنہ اور کب کیا انتخاب کریں

انحصار کی واضحیت — بنیادی فرق۔ DI انحصار کو واضح طور پر اعلان کرتا ہے: init(service: ServiceProtocol) — کوئی بھی IDE کلاس کے انحصار دکھاتا ہے۔ Service Locator انہیں چھپاتا ہے: dependencies = ServiceLocator.resolve() — طریقہ کار کے اندر چھپا ہوا۔ DI کے ساتھ، آپ فوری طور پر تمام کلاس انحصار دیکھ سکتے ہیں؛ Service Locator کے ساتھ، آپ کو پورا کلاس باڈی پڑھنے کی ضرورت ہے۔ یہ Service Locator کوڈ کو کم پیش قیاسی بناتا ہے: رجسٹری کو تبدیل کرنا لوکیٹر استعمال کرنے والی کسی بھی کلاس کو توڑ سکتا ہے۔

Service Locator کب جائز ہے — پروٹوٹائپ اور MVP (ترتیب کے بغیر تیز شروع)۔ وراثتی منصوبے جہاں DI فریم ورک شامل کرنا ناممکن ہے (پیچیدہ تعمیر، لنٹر پابندیاں)۔ آلات کی لائبریریاں (لاگنگ، کریش رپورٹنگ) — وہ پہلے سے ہی عالمی ہیں۔ 3+ ڈویلپرز کی ٹیم کے ساتھ پروڈکشن ایپلیکیشنز کے لئے، DI تجویز کیا جاتا ہے: واضح انحصار ری فیکٹرنگ کے دوران غلطیوں کی تعداد کو کم کرتے ہیں اور نئے ڈویلپرز کو شامل کرنا آسان بناتے ہیں۔

Service Locator کے مسائل اور متبادل

چھپے ہوئے انحصار — ایک کلاس جو طریقہ کار کے اندر ServiceLocator.resolve() استعمال کرتی ہے، جامد طور پر تجزیہ نہیں کی جا سکتی۔ IDE انحصار نہیں دکھاتا، کمپائلر چیک نہیں کرتا کہ سروس رجسٹر ہے یا نہیں۔ "Service not registered" خرابی صرف رن ٹائم پر ہوتی ہے۔ ری فیکٹرنگ خطرناک ہو جاتی ہے: رجسٹری سے سروس ہٹانا ایپلیکیشن میں کسی بھی کلاس کو توڑ سکتا ہے۔ DI اس مسئلے کو کمپائل ٹائم چیک (Dagger) یا واضح کنسٹرکٹرز کے ذریعے حل کرتا ہے۔

جانچ کا مسئلہ — ہر ٹیسٹ کو تمام انحصار کے ساتھ ServiceLocator.shared ترتیب دینا چاہیے۔ ٹیسٹ کے بعد — حالت دوبارہ سیٹ کریں۔ متوازی ٹیسٹ پر عملدرآمد کے دوران، ServiceLocator.shared کی عالمی حالت دوڑ کے حالات کا باعث بنتی ہے: ایک ٹیسٹ mock رجسٹر کرتا ہے، دوسرا ٹیسٹ کسی اور کا mock حاصل کرتا ہے۔ حل: دائرہ کار والے لوکیٹر (ایک فی ٹیسٹ) یا ThreadLocal۔ DI اس مسئلے کو شروع سے حل کرتا ہے: ہر ٹیسٹ mock انحصار کے ساتھ اپنی مثال بناتا ہے۔

// Service Locator کی جانچ کا مسئلہ
class LoginViewModelTests: XCTestCase {
    override func setUp() {
        super.setUp()
        // ٹیسٹ کے لئے عالمی رجسٹری ترتیب
        ServiceLocator.shared.register(AuthServiceProtocol.self) { MockAuthService() }
    }

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

    func testLogin() {
        let viewModel = LoginViewModel() // اندرونی طور پر ServiceLocator استعمال کرتا ہے
        // ٹیسٹ...
    }
}

Service Locator کے متبادل — DI (Dagger, Swinject)، Factory Method، Ambient Context۔ Factory Method — عالمی حالت کے بغیر ایک سادہ پیٹرن: ایک فیکٹری کلاس خدمات بناتی ہے اور کنسٹرکٹر کے ذریعے منتقل کی جاتی ہے۔ Ambient Context — کراس کٹنگ خدشات (لاگنگ، اجازت) کے لئے ایک تھریڈ سیف متبادل۔ بہترین متبادل DI فریم ورک کے بغیر دستی فیکٹری کے ساتھ Constructor Injection ہے: کنسٹرکٹر منتقلی کے ساتھ فیکٹری میں انحصار کی واضح تخلیق Dagger/Swinject کی ترتیب کی پیچیدگی کے بغیر DI وضاحت فراہم کرتی ہے۔