Dependency injection
سافٹ ویئر انجینئرنگ میں، انحصار انجکشن ایک پروگرامنگ تکنیک ہے جس میں کسی شے یا فنکشن کو دیگر اشیاء یا افعال موصول ہوتے ہیں جن کی اسے ضرورت ہوتی ہے، بجائے اس کے کہ انہیں اندرونی طور پر بنایا جائے۔ انحصار انجکشن کا مقصد اشیاء کی تعمیر اور ان کے استعمال کے خدشات کو الگ کرنا ہے، جس کی وجہ سے ڈھیلے جوڑے والے پروگرام ہوتے ہیں۔ پیٹرن اس بات کو یقینی بناتا ہے کہ کوئی آبجیکٹ یا فنکشن جو دی گئی سروس کو استعمال کرنا چاہتا ہے اسے ان سروسز کی تعمیر کا طریقہ نہیں جاننا چاہیے۔ اس کے بجائے، وصول کرنے والے 'کلائنٹ' (آبجیکٹ یا فنکشن) کو اس کے انحصار بیرونی کوڈ (ایک 'انجیکٹر') کے ذریعے فراہم کیے جاتے ہیں، جس سے وہ واقف نہیں ہے۔ انحصار انجکشن مضمر انحصار کو واضح بناتا ہے اور مندرجہ ذیل مسائل کو حل کرنے میں مدد کرتا ہے: ایک طبقہ ان اشیاء کی تخلیق سے کیسے آزاد ہو سکتا ہے جن پر وہ انحصار کرتا ہے؟ کوئی ایپلیکیشن، اور اس کے استعمال کردہ آبجیکٹ مختلف ترتیبات کی حمایت کیسے کر سکتے ہیں؟ کوڈ کے کسی ٹکڑے کے رویے کو براہ راست ترمیم کیے بغیر کیسے تبدیل کیا جا سکتا ہے؟ انحصار انجکشن اکثر کوڈ کو انحصار الٹ اصول کے مطابق رکھنے کے لیے استعمال کیا جاتا ہے۔ جامد طور پر ٹائپ شدہ زبانوں میں انحصار انجکشن کا استعمال کرنے کا مطلب ہے کہ کلائنٹ کو صرف ان خدمات کے انٹرفیس کا اعلان کرنے کی ضرورت ہے جو وہ استعمال کرتا ہے، بجائے ان کے ٹھوس نفاذ کے، جس سے یہ تبدیل کرنا آسان ہو جاتا ہے کہ کون سی خدمات کو دوبارہ مرتب کیے بغیر رن ٹائم پر استعمال کیا جاتا ہے۔ ایپلیکیشن فریم ورک اکثر انحصار انجکشن کو کنٹرول کے الٹ کے ساتھ جوڑتے ہیں۔ کنٹرول کے الٹ کے تحت، فریم ورک پہلے کسی شے (جیسے کنٹرولر) کی تعمیر کرتا ہے، پھر اس پر کنٹرول کا بہاؤ منتقل کرتا ہے۔ انحصار انجکشن کے ساتھ، فریم ورک ایپلی کیشن آبجیکٹ (اکثر کنسٹرکٹر طریقہ کے پیرامیٹرز میں) کے ذریعہ اعلان کردہ انحصار کو بھی فوری کرتا ہے، اور انحصار کو آبجیکٹ میں منتقل کرتا ہے۔ انحصار انجکشن "انحصار کے نفاذ پر الٹا کنٹرول" کے خیال کو نافذ کرتا ہے، یہی وجہ ہے کہ کچھ جاوا فریم ورک عام طور پر تصور کو "کنٹرول کا الٹا" (کنٹرول فلو کے الٹا کے ساتھ الجھن میں نہ پڑنا) کا نام دیتے ہیں۔ رولز ڈیپینڈینسی انجیکشن میں چار کردار شامل ہیں: سروسز، کلائنٹس، انٹرفیس اور انجیکٹر۔ خدمات اور کلائنٹ ایک خدمت کوئی بھی کلاس ہے جس میں مفید فعالیت ہوتی ہے۔ بدلے میں، کلائنٹ کوئی بھی طبقہ ہوتا ہے جو خدمات استعمال کرتا ہے۔ کلائنٹ کو جن خدمات کی ضرورت ہوتی ہے وہ کلائنٹ کا انحصار ہے۔ کوئی بھی شے خدمت یا کلائنٹ ہو سکتی ہے ؛ ان کے ناموں کا تعلق صرف اس کردار سے ہوتا ہے جو اشیاء انجکشن میں ادا کرتے ہیں۔ ایک ہی شے کلائنٹ (یہ انجکشن شدہ خدمات استعمال کرتا ہے) اور سروس (یہ دوسری اشیاء میں انجکشن کی جاتی ہے) دونوں بھی ہو سکتی ہے۔ انجکشن لگانے کے بعد، سروس کو کلائنٹ کی ریاست کا حصہ بنایا جاتا ہے، جو استعمال کے لیے دستیاب ہوتا ہے۔ انٹرفیس کلائنٹس کو یہ نہیں معلوم ہونا چاہیے کہ ان کے انحصار کو کس طرح نافذ کیا جاتا ہے، صرف ان کے نام اور API۔ ایک سروس جو ای میلز کو بازیافت کرتی ہے، مثال کے طور پر، پردے کے پیچھے آئی ایم اے پی یا پی او پی 3 پروٹوکول استعمال کر سکتی ہے، لیکن یہ تفصیل ممکنہ طور پر کالنگ کوڈ سے غیر متعلقہ ہے جو محض ای میل کو بازیافت کرنا چاہتی ہے۔ عمل درآمد کی تفصیلات کو نظر انداز کرنے سے، گاہکوں کو ان کے انحصار کے وقت تبدیل کرنے کی ضرورت نہیں ہے۔ انجیکٹر، جسے بعض اوقات اسمبلر، کنٹینر، فراہم کنندہ یا فیکٹری بھی کہا جاتا ہے، کلائنٹ کو خدمات متعارف کراتا ہے۔ انجیکٹر کا کردار پیچیدہ آبجیکٹ گراف کی تعمیر اور جوڑنا ہے، جہاں آبجیکٹ کلائنٹ اور خدمات دونوں ہو سکتے ہیں۔ انجیکٹر خود ایک ساتھ کام کرنے والی بہت سی اشیاء ہو سکتی ہیں، لیکن کلائنٹ نہیں ہونا چاہیے، کیونکہ اس سے سرکلر انحصار پیدا ہوگا۔ چونکہ انحصار انجکشن الگ کرتا ہے کہ اشیاء کی تعمیر کس طرح کی جاتی ہے اور ان کے استعمال کے طریقے سے، یہ اکثر زیادہ تر آبجیکٹ پر مبنی زبانوں میں پائے جانے والے نئے مطلوبہ الفاظ کی اہمیت کو کم کرتا ہے۔ چونکہ فریم ورک خدمات تخلیق کرنے کو سنبھالتا ہے، اس لیے پروگرامر صرف براہ راست ویلیو آبجیکٹ کی تعمیر کرتا ہے جو پروگرام کے ڈومین میں موجود اداروں کی نمائندگی کرتا ہے (جیسے کاروباری ایپ میں ایمپلائی آبجیکٹ یا شاپنگ ایپ میں آرڈر آبجیکٹ)۔ مشابہت ایک مشابہت کے طور پر، کاروں کو ایسی خدمات کے طور پر سمجھا جا سکتا ہے جو لوگوں کو ایک جگہ سے دوسری جگہ لے جانے کا مفید کام انجام دیتی ہیں۔ کار کے انجنوں کو گیس، ڈیزل یا بجلی کی ضرورت پڑ سکتی ہے، لیکن یہ تفصیل کلائنٹ-ایک ڈرائیور-کے لیے غیر اہم ہے جو صرف اس بات کی پرواہ کرتا ہے کہ آیا یہ انہیں ان کی منزل تک پہنچا سکتا ہے۔ کاریں اپنے پیڈل، اسٹیئرنگ وہیل اور دیگر کنٹرول کے ذریعے یکساں انٹرفیس پیش کرتی ہیں۔ اس طرح، فیکٹری لائن پر انہیں کس انجن کے ساتھ 'انجکشن' کیا گیا تھا اس سے کوئی فرق نہیں پڑتا ہے اور ڈرائیور ضرورت کے مطابق کسی بھی قسم کی کار کے درمیان تبدیل کر سکتے ہیں۔ فوائد اور نقصانات انحصار انجکشن کا ایک بنیادی فائدہ کلاسوں اور ان کے انحصار کے درمیان جوڑے میں کمی ہے۔ کلائنٹ کے علم کو ہٹانے سے کہ اس کے انحصار کو کس طرح نافذ کیا جاتا ہے، پروگرام زیادہ دوبارہ استعمال کے قابل، قابل جانچ اور برقرار رکھنے کے قابل بن جاتے ہیں۔ اس کے نتیجے میں لچک میں بھی اضافہ ہوتا ہے: ایک کلائنٹ کسی بھی ایسی چیز پر عمل کر سکتا ہے جو کلائنٹ کی توقع کے مطابق اندرونی انٹرفیس کی حمایت کرتا ہے۔ زیادہ عام طور پر، انحصار انجکشن بوائیلر پلیٹ کوڈ کو کم کرتا ہے، کیونکہ انحصار کی تمام تخلیق کو ایک واحد جزو کے ذریعے سنبھالا جاتا ہے۔ آخر میں، انحصار انجکشن بیک وقت ترقی کی اجازت دیتا ہے۔ دو ڈویلپر آزادانہ طور پر ایسی کلاسیں تیار کر سکتے ہیں جو ایک دوسرے کو استعمال کرتی ہیں، جبکہ صرف اس انٹرفیس کو جاننے کی ضرورت ہوتی ہے جس کے ذریعے کلاسیں بات چیت کریں گی۔ پلگ ان اکثر تیسرے فریق کے ذریعہ تیار کیے جاتے ہیں جو اصل پروڈکٹ کے ڈویلپرز سے کبھی بات بھی نہیں کرتے ہیں۔ انحصار انجکشن کے بہت سے فوائد یونٹ ٹیسٹنگ کے لیے خاص طور پر متعلقہ ہیں۔ مثال کے طور پر، انحصار انجکشن کو سسٹم کی ترتیب کی تفصیلات کو ترتیب فائلوں میں بیرونی بنانے کے لیے استعمال کیا جا سکتا ہے، جس سے سسٹم کو دوبارہ مرتب کیے بغیر دوبارہ ترتیب دیا جا سکتا ہے۔ مختلف حالات کے لیے علیحدہ ترتیبات لکھی جا سکتی ہیں جن میں اجزاء کے مختلف نفاذ کی ضرورت ہوتی ہے۔ اسی طرح، کیونکہ انحصار انجکشن کو کوڈ کے رویے میں کسی تبدیلی کی ضرورت نہیں ہے، اس کا اطلاق میراث کوڈ پر ری فیکٹرنگ کے طور پر کیا جا سکتا ہے۔ یہ کلائنٹس کو زیادہ آزاد بناتا ہے اور اسٹب یا فرضی اشیاء کا استعمال کرتے ہوئے الگ تھلگ یونٹ ٹیسٹ کرنا آسان بناتا ہے، جو دیگر اشیاء کی تقلید کرتے ہیں جو ٹیسٹ کے تحت نہیں ہیں۔ جانچ کی یہ آسانی اکثر انحصار انجکشن کا استعمال کرتے وقت دیکھا جانے والا پہلا فائدہ ہوتا ہے۔ نقصانات انحصار انجکشن کے ناقدین کا کہنا ہے کہ یہ: ایسے کلائنٹ بناتا ہے جو ترتیب کی تفصیلات کا مطالبہ کرتے ہیں، جو واضح ڈیفالٹ دستیاب ہونے پر مشکل ہو سکتے ہیں۔ کوڈ کا سراغ لگانا مشکل بنا دیتا ہے کیونکہ یہ رویے کو تعمیر سے الگ کرتا ہے۔ عام طور پر عکاسی یا متحرک پروگرامنگ کے ساتھ لاگو کیا جاتا ہے، جو آئی ڈی ای آٹومیشن میں رکاوٹ ہے۔ عام طور پر زیادہ پیشگی ترقیاتی کوششوں کی ضرورت ہوتی ہے۔ کسی فریم ورک پر انحصار کی حوصلہ افزائی کرتا ہے۔ انحصار انجکشن کی اقسام تین اہم طریقے ہیں جن میں ایک کلائنٹ انجکشن کی خدمات حاصل کر سکتا ہے: کنسٹرکٹر انجکشن، جہاں انحصار کلائنٹ کے کلاس کنسٹرکٹر کے ذریعے فراہم کیے جاتے ہیں۔ سیٹر انجکشن، جہاں کلائنٹ ایک سیٹر طریقہ کو بے نقاب کرتا ہے جو انحصار کو قبول کرتا ہے۔ انٹرفیس انجکشن، جہاں انحصار کا انٹرفیس ایک انجیکٹر طریقہ فراہم کرتا ہے جو انحصار کو کسی بھی کلائنٹ میں منتقل کرے گا۔ کچھ فریم ورک میں، کلائنٹس کو فعال طور پر انحصار انجکشن کو بالکل قبول کرنے کی ضرورت نہیں ہے۔ مثال کے طور پر، جاوا میں، براہ راست خدمات کی جانچ اور انجیکشن کرتے وقت عکاسی نجی صفات کو عام کر سکتی ہے۔ انحصار انجکشن کے بغیر مندرجہ ذیل جاوا مثال میں، کلائنٹ کلاس میں ایک سروس ممبر متغیر ہوتا ہے جو کنسٹرکٹر میں شروع ہوتا ہے۔ کلائنٹ براہ راست تعمیر اور کنٹرول کرتا ہے کہ وہ کون سی خدمت استعمال کرتا ہے، جس سے ہارڈ کوڈڈ انحصار پیدا ہوتا ہے۔ پبلک کلاس کلائنٹ {پرائیویٹ سروس سروس ؛ کلائنٹ () {// انحصار ہارڈ کوڈڈ ہے۔ this.service = نئی مثال سروس () ؛} کنسٹرکٹر انجکشن انحصار انجکشن کی سب سے عام شکل کلاس کے لیے اپنے کنسٹرکٹر کے ذریعے اپنے انحصار کی درخواست کرنا ہے۔ یہ اس بات کو یقینی بناتا ہے کہ کلائنٹ ہمیشہ درست حالت میں رہے، کیونکہ اسے اس کے ضروری انحصار کے بغیر فوری نہیں کیا جا سکتا۔ پبلک کلاس کلائنٹ {پرائیویٹ سروس سروس ؛// انحصار ایک کنسٹرکٹر کے ذریعے انجکشن کیا جاتا ہے۔ کلائنٹ (سروس سروس) {اگر (سروس = = کالعدم) {نیا غیر قانونی آرگمینٹ ایکسپشن پھینک دیں ("سروس کالعدم نہیں ہونی چاہیے") ؛} this.service = سروس ؛}} سیٹر انجکشن کنسٹرکٹر کے بجائے سیٹر طریقہ کے ذریعے انحصار کو قبول کرکے، کلائنٹ انجیکٹرز کو کسی بھی وقت اپنے انحصار کو جوڑنے کی اجازت دے سکتے ہیں۔ یہ لچک پیش کرتا ہے، لیکن اس بات کو یقینی بنانا مشکل بنا دیتا ہے کہ کلائنٹ کے استعمال سے پہلے تمام انحصار انجکشن اور درست ہیں۔ پبلک کلاس کلائنٹ {پرائیویٹ سروس سروس ؛// انحصار ایک سیٹر طریقہ کے ذریعے انجکشن کیا جاتا ہے۔ عوامی کالعدم سیٹ سروس (سروس سروس) {اگر (سروس = = کالعدم) {نیا غیر قانونی دلیل چھوڑیں ("سروس کالعدم نہیں ہونی چاہیے") ؛} this.service = سروس ؛} انٹرفیس انجکشن انٹرفیس انجکشن کے ساتھ، انحصار اپنے کلائنٹس سے مکمل طور پر ناواقف ہیں، پھر بھی نئے کلائنٹس کو حوالہ جات بھیجتے اور وصول کرتے ہیں۔ اس طرح، انحصار انجیکٹر بن جاتے ہیں۔ کلیدی بات یہ ہے کہ انجیکشن کا طریقہ انٹرفیس کے ذریعے فراہم کیا جاتا ہے۔ کلائنٹ اور اس کے انحصار کو متعارف کرانے کے لیے اب بھی ایک اسمبلر کی ضرورت ہے۔ اسمبلر کلائنٹ کا حوالہ لیتا ہے، اسے سیٹر انٹرفیس پر ڈالتا ہے جو اس انحصار کو طے کرتا ہے، اور اسے اس انحصار آبجیکٹ پر منتقل کرتا ہے جو بدلے میں خود کو کلائنٹ کو واپس بھیجتا ہے۔ انٹرفیس انجکشن کی قدر کے لیے، انحصار کو صرف اپنے حوالے کو واپس کرنے کے علاوہ کچھ کرنا چاہیے۔ یہ دیگر انحصار کو حل کرنے کے لیے ایک فیکٹری یا ذیلی اسمبلر کے طور پر کام کر سکتا ہے، اس طرح مرکزی اسمبلر سے کچھ تفصیلات کو خلاصہ کر سکتا ہے۔ یہ حوالہ شمار ہو سکتا ہے تاکہ انحصار کو معلوم ہو کہ کتنے کلائنٹ اسے استعمال کر رہے ہیں۔ اگر انحصار گاہکوں کے مجموعے کو برقرار رکھتا ہے، تو یہ بعد میں ان سب کو خود کی ایک مختلف مثال کے ساتھ داخل کر سکتا ہے۔ پبلک انٹرفیس سروس سیٹر {وایڈ سیٹ سروس (سروس سروس) ؛} پبلک کلاس کلائنٹ امپلیمنٹ سروس سیٹر {پرائیویٹ سروس سروس ؛ @Override پبلک وایڈ سیٹ سروس (سروس سروس) {اگر (سروس = کالعدم) {نیا غیر قانونی دلیل چھوڑیں ("سروس کالعدم نہیں ہونی چاہیے") ؛} this.service = سروس ؛} پبلک کلاس سروس انجیکٹر {پرائیویٹ فائنل سیٹ <سروس سیٹر> کلائنٹ = نیا ہیش سیٹ <> () ؛ پبلک وایڈ انجیکشن (سروس سیٹر کلائنٹ) {this.clients.add (کلائنٹ) ؛ client.setService (نئی مثال سروس () ؛} پبلک وایڈ سوئچ () پبلک کلاس پروگرام {پبلک جامد وایڈ مین (سٹرنگ [] آرگس) {// سروس بنائیں۔ سروس سروس = نئی مثال سروس () ؛// خدمت کو کلائنٹ میں داخل کریں۔ کلائنٹ کلائنٹ = نیا کلائنٹ (سروس) ؛// اشیاء کا استعمال کریں۔ دستی تعمیر زیادہ پیچیدہ ہو سکتی ہے اور اس میں بلڈرز، فیکٹریاں، یا دیگر تعمیراتی نمونے شامل ہو سکتے ہیں۔ فریم ورک دستی انحصار انجکشن اکثر بڑے منصوبوں کے لیے تکلیف دہ اور غلطی کا شکار ہوتا ہے، جس سے فریم ورک کے استعمال کو فروغ ملتا ہے جو عمل کو خودکار بناتا ہے۔ دستی انحصار انجکشن ایک انحصار انجکشن فریم ورک بن جاتا ہے جب بلڈنگ کوڈ اب ایپلی کیشن کے لیے حسب ضرورت نہیں ہوتا ہے اور اس کے بجائے عالمگیر ہوتا ہے۔ مفید ہونے کے باوجود، انحصار انجکشن کرنے کے لیے ان ٹولز کی ضرورت نہیں ہے۔ کچھ فریم ورک، جیسے اسپرنگ، پروگرام کی ساخت کی منصوبہ بندی کے لیے بیرونی کنفیگریشن فائلوں کا استعمال کر سکتے ہیں: درآمد org.springframework.beans.factory.BeanFactory ؛ درآمد org.springframework.context.ApplicationContext ؛ درآمد org.springframework.context.support.ClassPathXmlApplicationContext ؛ پبلک کلاس انجیکٹر {پبلک اسٹیٹک وایڈ مین (سٹرنگ [] ارگس) {// تفصیلات کہ کون سی کنکریٹ سروس استعمال کرنے کے لیے ترتیب میں پروگرام سے الگ محفوظ کی جاتی ہے۔ BeanFactery beanfactery = new ClassPathXml اطلاقی سیاق و سباق ("Beans.xml") ؛ کلائنٹ کلائنٹ = (کلائنٹ) beanfactory.getBean ("کلائنٹ") ؛ System.out.println (client.greet () ؛}} یہاں تک کہ ممکنہ طور پر طویل اور پیچیدہ آبجیکٹ گراف کے ساتھ، کوڈ میں مذکور واحد کلاس انٹری پوائنٹ ہے، اس معاملے میں Client.Client نے اسپرنگ کے ساتھ کام کرنے کے لیے کوئی تبدیلی نہیں کی ہے اور وہ ایک پوجو ہے۔ موسم بہار کی مخصوص تشریحات اور کالوں کو بہت سے طبقات میں پھیلنے سے روکنے سے، نظام صرف موسم بہار پر ڈھیلا انحصار کرتا ہے۔ مثال اینگولر جے ایس مندرجہ ذیل مثال میں دکھایا گیا ہے کہ اینگولر جے ایس جزو انحصار انجکشن کے ذریعے سلام کی خدمت حاصل کر رہا ہے۔ فنکشن کچھ کلاس (گریٹر) {this.greeter = گریٹر ؛} SomeClass.prototype.doSomething = فنکشن (نام) {this.greeter.greet (نام) ؛} ہر اینگولر جے ایس ایپلی کیشن میں ایک سروس لوکیٹر ہوتا ہے جو انحصار کی تعمیر اور تلاش کا ذمہ دار ہوتا ہے۔ //ماڈیول وار مائی ماڈیول = angular.module ('مائی ماڈیول'، []) میں وائرنگ کی معلومات فراہم کریں ؛// انجیکٹر کو گریٹر سروس بنانے کا طریقہ سکھائیں۔ //گریٹر $ونڈو سروس پر منحصر ہے۔ myModule.factory ('گریٹر'، فنکشن ($ونڈو) {ریٹرن {گریٹ: فنکشن (ٹیکسٹ) {$window.alert (ٹیکسٹ);}} ؛}) ؛ اس کے بعد ہم ایک نیا انجیکٹر بنا سکتے ہیں جو گریٹر سروس سمیت مائی ماڈیول ماڈیول میں بیان کردہ اجزاء فراہم کرتا ہے۔ وار انجیکٹر = angular.injector (['مائی ماڈیول'، 'ng']) ؛ وار گریٹر = injector.get ('گریٹر') ؛ سروس لوکیٹر اینٹی پیٹرن سے بچنے کے لیے، اینگولر جے ایس ایچ ٹی ایم ایل ٹیمپلیٹس میں ڈیکلیریٹو نوٹیشن کی اجازت دیتا ہے جو انجیکٹر کو اجزاء بنانے کی اجازت دیتا ہے۔ <ڈیوی این جی-کنٹرولر = "مائی کنٹرولر"> <بٹن این جی-کلک = "سی ہیلو ()"> ہیلو </بٹن> </ڈیوی> فنکشن مائی کنٹرولر ($اسکوپ، گریٹر) {$scope.sayHello = فنکشن () {greeter.greet ('ہیلو ورلڈ') ؛} ؛} این جی-کنٹرولر ہدایت انجیکٹر کو کنٹرولر اور اس کے انحصار کی مثال بنانے کے لیے متحرک کرتی ہے۔ C #یہ نمونہ C #میں کنسٹرکٹر انجیکشن کی ایک مثال فراہم کرتا ہے۔ سسٹم کا استعمال کرتے ہوئے ؛ نیم اسپیس ڈیپینڈینسی انجیکشن ؛// ہمارے کلائنٹ کو صرف اس انٹرفیس کے بارے میں معلوم ہوگا، نہ کہ وہ کون سا مخصوص گیم پیڈ استعمال کر رہا ہے۔ انٹرفیس آئی گیمی پیڈ فنکشنلٹی {سٹرنگ گیٹ گیمی پیڈ نام () ؛ کالعدم سیٹ وائبریشن پاور (فلوٹ پاور) ؛}// درج ذیل خدمات مندرجہ بالا انٹرفیس کے ٹھوس نفاذ فراہم کرتی ہیں۔ کلاس ایکس باکس گیم پیڈ: آئی گیمی پیڈ فنکشنلٹی {فلوٹ وائبریشن پاور = 1.0f ؛ پبلک سٹرنگ گیٹ گیم پیڈ نام () => "ایکس بکس کنٹرولر" ؛ پبلک وایڈ سیٹ وائبریشن پاور (فلوٹ پاور) => this.vibrationPower = Math.Clamp (پاور، 0.0f، 1.0f) ؛} کلاس پلے اسٹیشن جوائسٹک: آئی گیمی پیڈ فنکشنلٹی {فلوٹ وائبریٹنگ پاور = 100.0f ؛ پبلک سٹرنگ گیٹ گیم پیڈ نام () => "پلے اسٹیشن کنٹرولر" ؛ پبلک وایڈ سیٹ وائبریشن پاور (فلوٹ پاور) => this.vibratingPower = Math.Clamp (پاور * 100.0f، 0.0f، 100.0f) کلاس گیم پیڈ {آئی گیمی پیڈ فنکشنلٹی گیم پیڈ فنکشنلٹی ؛// سروس کو کنسٹرکٹر کے ذریعے انجکشن کیا جاتا ہے اور مندرجہ بالا فیلڈ میں محفوظ کیا جاتا ہے۔ عوامی گیم پیڈ (آئی گیمی پیڈ فنکشنلٹی گیم پیڈ فنکشنلٹی) => this.gamepadFunctionality = گیم پیڈ فنکشنلٹی ؛ عوامی کالعدم شوکیس () {// انجکشن شدہ سروس استعمال کی جاتی ہے۔ وار گیم پیڈ نام = this.gamepadFunctionality.GetGamepadName () ؛ وار پیغام = $"ہم ابھی {گیم پیڈ نام} استعمال کر رہے ہیں، کیا آپ کمپن کی طاقت کو تبدیل کرنا چاہتے ہیں؟ "؛ Console.WriteLine (پیغام) ؛} کلاس پروگرام {جامد کالعدم مین () {وار سٹیم کنٹرولر = نیا اسٹیم کنٹرولر () ؛// ہم ایکس بکس کنٹرولر، پلے اسٹیشن جوئسٹک وغیرہ میں بھی پاس ہو سکتے تھے۔ //گیم پیڈ نہیں جانتا کہ وہ کیا استعمال کر رہا ہے اور اس کی ضرورت نہیں ہے۔ ور گیم پیڈ = نیا گیم پیڈ (سٹیم کنٹرولر) ؛ gamepad.Showcase () ؛} آرکیٹیکچر کی تفصیل زبان بھی دیکھیں فیکٹری پیٹرن کنٹرول پلگ ان کا الٹ (کمپیوٹنگ) اسٹریٹجی پیٹرن اینگولر جے ایس سروس لوکیٹر پیٹرن پیرامیٹر (کمپیوٹر پروگرامنگ) کواجکٹ حوالہ جات بیرونی لنکس کمپوزیشن روٹ بذریعہ مارک سیمن ایک ابتدائی رہنمائی انحصار انجکشن انحصار اور قابل جانچ اشیاء کے لیے: ڈھیلے جوڑے اور قابل جانچ اشیاء کو ڈیزائن کرنا-جیریمی ویسکوٹن ؛ ڈاکٹر ڈوبس جرنل، مئی 2006۔ ڈیزائن پیٹرن: انحصار انجکشن-- ایم ایس ڈی این میگزین، ستمبر 2005 مارٹن فاؤلر کا اصل مضمون جس نے ای اے اے کے انحصار انجکشن پی کی اصطلاح متعارف کرائی: انحصار انجکشن کے پیچھے امیر انجینئرنگ ہیریٹیج پلگ ان-اینڈریو میک ویگ-انحصار انجکشن کی ایک تفصیلی تاریخ۔ انحصار انجکشن کیا ہے؟ - ایک متبادل وضاحت-جیکب جینکوف انحصار انجکشن کے ساتھ مزید قابل جانچ کوڈ لکھ رہے ہیں-- Developer.com، اکتوبر 2006 منظم ایکسٹینسیبلٹی فریم ورک کا جائزہ-- ہنٹ 1998 ریفیکٹر کے ذریعے انحصار میکانزم کی پرانے زمانے کی تفصیل انحصار انجکشن کنٹینر کا راستہ پی ایچ پی میں ڈی آئی کو سمجھنا آپ کو انحصار انجکشن کنٹینر جزو پر مبنی سافٹ ویئر انجینئرنگ سافٹ ویئر فن تعمیر سافٹ ویئر ڈیزائن پیٹرن کی ضرورت نہیں ہے مثال کے طور پر جاوا کوڈ کے ساتھ مضامین