Swinject: یہ کیا ہے، Dependency Injection کے اصول اور کیسے کام کرتا ہے

Swinject اور Dependency Injection کیا ہے

Swinject Swift زبان کے لیے ایک اوپن سورس DI کنٹینر ہے، جو iOS، macOS اور watchOS کے لیے ایپلی کیشنز میں انحصار انجیکشن کو آسان بنانے کے لیے ڈیزائن کیا گیا ہے۔ فریم ورک Service Locator نقطہ نظر استعمال کرتا ہے: سروسز ایک مرکزی کنٹینر میں رجسٹر ہوتی ہیں، اور کنٹینر خود بخود انحصار گراف کو حل کرتا ہے جب کسی مثال کی درخواست کی جاتی ہے۔

Dependency Injection (DI) ایک ڈیزائن پیٹرن ہے جہاں آبجیکٹ اپنے انحصار اندرونی طور پر بنانے کے بجائے باہر سے حاصل کرتا ہے۔ یہ اجزاء کے درمیان وابستگی کو کم کرتا ہے، یونٹ ٹیسٹنگ کو آسان بناتا ہے اور صارف کوڈ میں تبدیلی کیے بغیر نفاذ کو تبدیل کرنے کی اجازت دیتا ہے۔

Martin Fowler (2004) کے مطابق، DI Inversion of Control کا ایک مخصوص معاملہ ہے اور کنسٹرکٹر، پراپرٹی یا میتھڈ انجیکشن کے ذریعے نافذ کیا جاتا ہے۔ Swinject اس عمل کو خودکار بناتا ہے، دستی طور پر فیکٹریاں اور سروس لوکیٹر لکھنے کی ضرورت کو ختم کرتا ہے۔

Swinject کو تین یا زیادہ سروسز والے پروجیکٹس میں استعمال کریں جن میں کراس انحصار ہوں، جہاں دستی آبجیکٹ کی تعمیر ابتدائی کوڈ کو پھلا دیتی ہے اور جانچ کی صلاحیت کو کم کرتی ہے۔

Swinject Apple کے ماحولیاتی نظام کے ساتھ قریب سے مربوط ہے اور Swift 3.0 سے شروع ہونے والے تمام Swift ورژن کو سپورٹ کرتا ہے۔ فریم ورک پلوں کے ذریعے Objective-C کے ساتھ مطابقت رکھتا ہے، جس سے مکمل کوڈ منتقلی کے بغیر موجودہ مخلوط زبان کے پروجیکٹس میں متعارف کرایا جا سکتا ہے۔ یہ خاص طور پر پانچ سال سے زیادہ کی ترقی کی تاریخ والی بڑی ایپلی کیشنز کے لیے اہم ہے۔

Swinject کنٹینر کیسے کام کرتا ہے

Swinject کنٹینر Container کلاس کے ذریعے نافذ کیا جاتا ہے، جو رجسٹرڈ سروسز کا رجسٹری محفوظ کرتا ہے۔ جب resolve طریقہ کار کو کال کیا جاتا ہے، کنٹینر ایک آبجیکٹ بناتا ہے، رجسٹریشن گراف کے ذریعے اپنے تمام انحصاروں کو تکراری طور پر حل کرتا ہے۔

Container اور Service

Container مرکزی آبجیکٹ ہے جہاں تجرید اور ان کے نفاذ کے درمیان نقشہ جات رجسٹر ہوتے ہیں۔ Service ایک پروٹوکول ہے جو معاہدہ متعین کرتا ہے، جبکہ Component ایک کلاس ہے جو اس پروٹوکول کو نافذ کرتی ہے۔ رجسٹریشن register طریقہ کار کا استعمال کرتے ہوئے کی جاتی ہے، جو سروس کی قسم اور ایک فیکٹری لیتا ہے۔

let container = Container()
container.register(Networking.self) { _ in
    NetworkService()
}
let service = container.resolve(Networking.self)

resolve طریقہ کار مخصوص پروٹوکول کے لیے رجسٹرڈ ٹھوس نفاذ کی ایک مثال واپس کرتا ہے۔ اگر کوئی انحصار رجسٹر نہیں ہے، کنٹینر ترقی کے دوران فوری مسئلہ کا پتہ لگانے کے لیے ایک مہلک خرابی پھینکتا ہے۔

رجسٹریشن اور نامزد سروسز

ہر رجسٹریشن ایک فیکٹری فنکشن اور منتخب اسکوپ کے ساتھ ایک اندراج بناتا ہے۔ ایک سروس کے مختلف ناموں کے ساتھ متعدد رجسٹریشن ہو سکتی ہیں، جس سے نام کے مطابق مخصوص نفاذ منتخب کیا جا سکتا ہے — مختلف ماحول (ترقی، اسٹیجنگ، پروڈکشن) کے لیے مفید۔

انحصار حل کرنے کا عمل تکراری طور پر کام کرتا ہے: جب کنٹینر ایک Component مثال بناتا ہے، یہ اس کے ابتدائیہ کا تجزیہ کرتا ہے اور ہر پیرامیٹر کے لیے متعلقہ قسم کے ساتھ resolve کو کال کرتا ہے۔ اگر کسی انحصار کے اپنے انحصار بھی ہیں، عمل اس وقت تک جاری رہتا ہے جب تک پورا گراف مکمل طور پر تعمیر نہ ہو جائے۔ گہرائی صرف دستیاب میموری تک محدود ہے، لیکن عملی طور پر شاذ و نادر ہی پانچ سطحوں سے تجاوز کرتی ہے۔

Swinject میں انحصار انجیکشن کے طریقے

Swinject انحصار انجیکشن کے تین اہم طریقوں کو سپورٹ کرتا ہے، ہر ایک آرکیٹیکچرل سیاق و سباق کے لحاظ سے قابل اطلاق ہے۔

Constructor Injection

Constructor Injection ابتدائیہ پیرامیٹرز کے ذریعے انحصار انجیکٹ کرتا ہے۔ یہ ترجیحی طریقہ ہے، اس بات کو یقینی بناتا ہے کہ آبجیکٹ تخلیق کے لمحے سے ہمیشہ درست حالت میں ہو۔ Swinject خود بخود کنسٹرکٹر کو دیے گئے تمام انحصاروں کو حل کرتا ہے۔

class LoginViewModel {
    private let authService: AuthProtocol

    init(authService: AuthProtocol) {
        self.authService = authService
    }
}

container.register(AuthProtocol.self) { _ in
    AuthService()
}
container.register(LoginViewModel.self) { r in
    LoginViewModel(authService: r.resolve(AuthProtocol.self)!)
}

Property Injection

Property Injection ابتدا کے بعد آبجیکٹ کی خصوصیات سیٹ کر کے انحصار انجیکٹ کرتا ہے۔ یہ استعمال کیا جاتا ہے جب انحصار اختیاری ہو یا کنسٹرکٹر کے ذریعے منتقل نہ کیا جا سکے، مثال کے طور پر، Storyboard کے ساتھ کام کرتے ہوئے، جہاں view controller خود بخود بنتا ہے۔ Swinject واضح resolve کال کے بغیر رن ٹائم پر خودکار پراپرٹی انجیکشن کے لیے @Inject تشریح کو سپورٹ کرتا ہے۔

Property Injection استعمال کرتے وقت، آبجیکٹ تک پہلی رسائی سے پہلے انحصار سیٹ کرنا یقینی بنانا ضروری ہے۔ بصورت دیگر، پراپرٹی nil رہے گی، جس سے غیر متوقع کریش ہو گا۔ Swinject Implicitly Unwrapped Optional میکانزم اور انحصار گراف حل کرنے کے مرحلے میں سخت توثیق کے ذریعے اس مسئلے کو حل کرتا ہے۔

Method Injection

Method Injection طریقہ کار کے پیرامیٹرز کے ذریعے انحصار انجیکٹ کرتا ہے۔ یہ ان سروسز کے لیے استعمال کیا جاتا ہے جو صرف ایک آپریشن کرنے کے لیے ضروری ہوں اور آبجیکٹ کی مستقل حالت کے طور پر محفوظ نہیں ہونی چاہئیں۔ یہ سب سے کم عام لیکن کال بیک کے لیے مفید انجیکشن طریقہ ہے۔

Swinject میں اسکوپ اور ان کا مقصد

ObjectScope ایک طریقہ کار ہے جو Swinject کنٹینر کے اندر بنائی گئی مثال کی زندگی کا دورانیہ متعین کرتا ہے۔ فریم ورک ObjectScopeProtocol کے ذریعے حسب ضرورت اسکوپ بنانے کی صلاحیت کے ساتھ تین بلٹ ان اسکوپ فراہم کرتا ہے۔

ObjectScope.graph

graph اسکوپ ڈیفالٹ ویلیو ہے۔ ہر resolve کال ایک نئی مثال بناتی ہے جو صرف انحصار گراف حل کرنے کی مدت تک زندہ رہتی ہے۔ یہ بغیر حالت کے سروسز کے لیے ایک محفوظ انتخاب ہے کیونکہ یہ کیشنگ سے میموری لیک کو ختم کرتا ہے۔

ObjectScope.container

container اسکوپ کنٹینر کے اندر ایک سنگلٹن ہے۔ مثال پہلے resolve پر ایک بار بنائی جاتی ہے اور بعد کی تمام درخواستوں پر واپس کی جاتی ہے۔ مشترکہ حالت والی سروسز کے لیے موزوں: ڈیٹا کیش، لاگر، ایپلی کیشن سیٹنگز۔

ObjectScope.transient

transient اسکوپ کیشنگ کے بغیر ہر resolve کال پر ایک نئی مثال بناتا ہے۔ ہلکی پھلکی اشیاء کے لیے استعمال کیا جاتا ہے جنہیں دوبارہ استعمال کرنے کی ضرورت نہیں — مثال کے طور پر، ماڈیول جو ایک مخصوص HTTP درخواست کو ہینڈل کرتے ہیں۔

iOS پروجیکٹس میں Swinject

ایک حقیقی iOS پروجیکٹ میں Swinject کو ضم کرنا ایپلی کیشن کے آغاز پر کنٹینر کو ابتدائی کرنے سے شروع ہوتا ہے — AppDelegate یا سین میں۔ Assembly کے ذریعے رجسٹریشن کو ترتیب دینے کی سفارش کی جاتی ہے: ایک علیحدہ کلاس یا ساخت جو متعلقہ سروسز کو گروپ کرتی ہے۔

Swift Developer Community سروے (2025) کے مطابق، 43% iOS ڈویلپر تجارتی پروجیکٹس میں نیٹ ورک پرت، ذخیروں اور نیویگیشن کوآرڈینیٹر کے انحصار کو منظم کرنے کے لیے DI کنٹینر استعمال کرتے ہیں۔ Swinject اپنے کم سے کم نحو اور Objective-C مطابقت کی وجہ سے سب سے مقبول حل ہے۔

Storyboard Injection Swinject کی ایک منفرد خصوصیت ہے: کنٹینر AppDelegate میں اضافی کوڈ کے بغیر Storyboard سے بنائے گئے view controller میں خود بخود انحصار انجیکٹ کرتا ہے۔ یہ init(container:) طریقہ کار کے ذریعے UIStoryboard کو بھیجے گئے ایک خاص حل کرنے والے کا استعمال کرتا ہے، جو view controller کی تخلیق کو روکتا ہے اور رجسٹرڈ انحصار کو انجیکٹ کرتا ہے۔

بڑے پروجیکٹس میں، Swinject کو نیویگیشن کوآرڈینیٹر کے ساتھ ملایا جا سکتا ہے: کوآرڈینیٹر کنٹینر وصول کرتا ہے اور resolve کے ذریعے ان کے انحصار کو حل کر کے اسکرینز بناتا ہے، پورے سین کے لیے ایک ترتیب نقطہ برقرار رکھتا ہے۔

Assembly آرکیٹیکچر رجسٹریشن کو منظم کرنے کے لیے تجویز کردہ پیٹرن ہے۔ ہر Assembly متعلقہ سروسز کو گروپ کرتا ہے (مثال کے طور پر، NetworkingAssembly، DatabaseAssembly) اور دوسرے Assembly پر منحصر ہو سکتا ہے۔ کنٹینر کو ابتدائی کرتے وقت، تمام Assembly لوڈ ہوتے ہیں اور اپنی سروسز رجسٹر کرتے ہیں، واضح ذمہ داری کی علیحدگی فراہم کرتے ہیں اور درجنوں سروسز والے بڑے پروجیکٹس میں DI ترتیب میں نیویگیشن کو آسان بناتے ہیں۔

DI گراف کو ڈیبگ کرنے کے لیے، Swinject SwinjectPropertyLoader ایکسٹینشن فراہم کرتا ہے، جو plist فائل سے ترتیب لوڈ کرتا ہے، اور SwinjectStoryboard — UIStoryboard کے ایک خاص ورژن کے ذریعے اسٹوری بورڈ انضمام۔ یہ اوزار خاص طور پر اس وقت مفید ہوتے ہیں جب کسی موجودہ پروجیکٹ کو دستی آبجیکٹ کی تعمیر سے DI میں منتقل کیا جائے: ڈویلپر بتدریج سروسز رجسٹر کر سکتا ہے، اہم فیچر کی ترقی کو روکے بغیر ٹیسٹ اور حل کی خرابی لاگنگ کے ذریعے انحصار گراف کی جانچ کر سکتا ہے۔

Swinject واضح فیکٹری رجسٹریشن کے بغیر ابتدائیہ پیرامیٹر کی اقسام پر مبنی خودکار انحصار حل کرنے کے لیے SwinjectAutoregistration ایکسٹینشن کے ذریعے RxSwift اور Combine کے ساتھ انضمام بھی فراہم کرتا ہے۔ یہ سادہ سروسز کے لیے رجسٹریشن کوڈ کی مقدار کو کم کرتا ہے: فیکٹری متعین کیے بغیر صرف container.register(ServiceProtocol.self) کال کریں، اور Swinject Swift رن ٹائم کے فراہم کردہ Signal عکاسی پر مبنی خود بخود فیکٹری بنا دے گا۔ یہ نقطہ نظر ان سروسز کے لیے تجویز کیا جاتا ہے جن کے کنسٹرکٹر صرف بنیادی اقسام قبول کرتے ہیں اور پیچیدہ تخلیق منطق کی ضرورت نہیں ہوتی۔