निर्भरता इंजेक्शन मूल बातें

इस लेख में, मैं एक सरल भाषा में निर्भरता इंजेक्शन (Eng। निर्भरता इंजेक्शन, DI ) की मूल बातें और इस दृष्टिकोण का उपयोग करने के कारणों के बारे में भी बात करूंगा। यह लेख उन लोगों के लिए है जो यह नहीं जानते हैं कि निर्भरता इंजेक्शन क्या है, या जो इस तकनीक का उपयोग करने की आवश्यकता पर संदेह करते हैं। तो चलिए शुरू करते हैं।

नशा क्या है?

आइए पहले एक उदाहरण देखें। हम नीचे दिखाए गए अनुसार ClassC , ClassB और ClassC हैं:

 class ClassA { var classB: ClassB } class ClassB { var classC: ClassC } class ClassC { } 

आप देख सकते हैं कि क्लास क्लास में ClassB क्लास का एक उदाहरण है, इसलिए हम कह सकते हैं कि क्लास क्लास क्लास क्लास पर निर्भर करता है। क्यों? क्योंकि ClassB को सही ढंग से काम करने के लिए ClassB आवश्यकता ClassB है। हम यह भी कह सकते हैं कि ClassB क्लास क्लास क्लास की निर्भरता है।

जारी रखने से पहले, मैं स्पष्ट करना चाहता हूं कि ऐसा संबंध अच्छा है, क्योंकि हमें आवेदन में सभी काम करने के लिए एक वर्ग की आवश्यकता नहीं है। हमें तर्क को विभिन्न वर्गों में विभाजित करने की आवश्यकता है, जिनमें से प्रत्येक एक निश्चित फ़ंक्शन के लिए जिम्मेदार होगा। और इस मामले में, कक्षाएं प्रभावी ढंग से बातचीत करने में सक्षम होंगी।

निर्भरता के साथ कैसे काम करें?

आइए निर्भरता इंजेक्शन कार्यों को करने के लिए उपयोग किए जाने वाले तीन तरीकों को देखें:

पहला तरीका: एक आश्रित वर्ग में निर्भरता पैदा करें

सीधे शब्दों में कहें तो हम जब भी जरूरत हो वस्तुओं को बना सकते हैं। निम्नलिखित उदाहरण पर एक नज़र डालें:

 class ClassA { var classB: ClassB fun someMethodOrConstructor() { classB = ClassB() classB.doSomething() } } 

यह बहुत आसान है! हम एक वर्ग बनाते हैं जब हमें इसकी आवश्यकता होती है।

लाभ

• यह आसान और सरल है।
• आश्रित वर्ग (हमारे मामले में ClassA ) पूरी तरह से नियंत्रण करता है कि निर्भरता कैसे और कब बनाई जाए।

कमियों

• ClassB और ClassB एक दूसरे से निकटता से संबंधित ClassB । इसलिए, जब भी हमें ClassB का उपयोग करने की आवश्यकता होती है, तो हमें ClassB का उपयोग करने के लिए मजबूर किया जाएगा, और ClassB को किसी अन्य चीज़ से बदलना असंभव होगा ।
• ClassB वर्ग के आरंभीकरण में किसी भी बदलाव के साथ, आपको ClassB वर्ग (और ClassB पर निर्भर अन्य सभी वर्गों) के अंदर कोड को समायोजित करने की आवश्यकता होगी। यह निर्भरता बदलने की प्रक्रिया को जटिल बनाता है।
• ClassA परीक्षण नहीं किया जा सकता है। यदि आपको एक वर्ग का परीक्षण करने की आवश्यकता है, और फिर भी यह सॉफ्टवेयर विकास के सबसे महत्वपूर्ण पहलुओं में से एक है, तो आपको प्रत्येक कक्षा का इकाई परीक्षण अलग से करना होगा। इसका मतलब यह है कि यदि आप ClassA से ClassA क्लास के सही संचालन को सत्यापित करना चाहते हैं और इसे जांचने के लिए कई यूनिट टेस्ट बनाते हैं, तो, जैसा कि उदाहरण में दिखाया गया है, आप किसी भी स्थिति में ClassB क्लास का एक उदाहरण ClassB , भले ही यह आपके लिए हित का न हो। यदि परीक्षण के दौरान कोई त्रुटि होती है, तो आप यह नहीं समझ पाएंगे कि यह कहाँ स्थित है - ClassB या ClassB । आखिरकार, ऐसी संभावना है कि ClassB में कोड का एक हिस्सा त्रुटि का कारण बना, जबकि ClassB सही ढंग ClassA काम कर रहा है। दूसरे शब्दों में, यूनिट परीक्षण संभव नहीं है क्योंकि मॉड्यूल (कक्षाएं) एक दूसरे से अलग नहीं किए जा सकते हैं।
• ClassA को कॉन्फ़िगर किया जाना चाहिए ताकि यह निर्भरता को इंजेक्ट कर सके। हमारे उदाहरण में, उसे यह जानने की जरूरत है कि ClassC कैसे बनाई ClassC और इसका इस्तेमाल ClassB बनाने के लिए किया ClassB । यह बेहतर होगा यदि वह इसके बारे में कुछ भी नहीं जानता। क्यों? एकल जिम्मेदारी के सिद्धांत के कारण।

प्रत्येक वर्ग को केवल अपना काम करना चाहिए।

इसलिए, हम नहीं चाहते हैं कि कक्षाएं अपने कार्यों के अलावा किसी अन्य चीज के लिए जिम्मेदार हों। निर्भरता का कार्यान्वयन एक अतिरिक्त कार्य है जो हम उनके लिए निर्धारित करते हैं।

दूसरा तरीका: एक कस्टम वर्ग के माध्यम से निर्भरता को इंजेक्ट करें

इसलिए, यह समझना कि एक आश्रित वर्ग के भीतर निर्भरता को इंजेक्ट करना एक अच्छा विचार नहीं है, चलो एक वैकल्पिक तरीका तलाशते हैं। यहां, आश्रित वर्ग सभी निर्भरता को परिभाषित करता है जो उसे निर्माणकर्ता के अंदर की आवश्यकता होती है और उपयोगकर्ता वर्ग को उन्हें प्रदान करने की अनुमति देता है। क्या यह हमारी समस्या का समाधान है? हम थोड़ी देर बाद पता लगाएंगे।

नीचे दिए गए नमूना कोड पर एक नज़र डालें:

 class ClassA { var classB: ClassB constructor(classB: ClassB){ this.classB = classB } } class ClassB { var classC: ClassC constructor(classC: ClassC){ this.classC = classC } } class ClassC { constructor(){ } } class UserClass(){ fun doSomething(){ val classC = ClassC(); val classB = ClassB(classC); val classA = ClassA(classB); classA.someMethod(); } } view rawDI Example In Medium - 

अब ClassA को कंस्ट्रक्टर के अंदर सभी निर्भरताएं मिलती हैं और बस ClassB के तरीकों को बिना कुछ ClassB कॉल कर सकते हैं।

लाभ

• ClassB और ClassB अब शिथिल युग्मित हैं, और हम ClassB के अंदर कोड को तोड़ने के बिना ClassB को बदल सकते हैं। उदाहरण के लिए, ClassB पास करने के बजाय ClassB हम AssumeClassB पास कर सकते हैं, जो ClassB उपवर्ग है, और हमारा प्रोग्राम ठीक से काम करेगा।
• अब ClassA परीक्षण किया जा सकता है। यूनिट टेस्ट लिखते समय, हम ClassB (टेस्ट ऑब्जेक्ट) का अपना संस्करण बना सकते हैं और इसे ClassB पास कर सकते हैं। यदि परीक्षा पास करते समय कोई त्रुटि होती है, तो अब हम यह जानते हैं कि यह निश्चित रूप से ClassA में एक त्रुटि है।
• ClassB निर्भरता के साथ काम करने से मुक्त किया जाता है और इसके कार्यों पर ध्यान केंद्रित किया जा सकता है।

कमियों

• यह विधि एक श्रृंखला तंत्र जैसा दिखता है, और कुछ बिंदु पर श्रृंखला को बाधित किया जाना चाहिए। दूसरे शब्दों में, ClassB वर्ग के उपयोगकर्ता को ClassB के आरंभीकरण के बारे में सब कुछ पता होना चाहिए, जिससे बदले में ClassC के आरंभ के बारे में ज्ञान की आवश्यकता होती है, आदि। तो, आप देखते हैं कि इनमें से किसी भी वर्ग के निर्माता में किसी भी परिवर्तन से कॉलिंग क्लास में बदलाव हो सकता है, यह उल्लेख नहीं करने के लिए कि ClassA एक से अधिक उपयोगकर्ता हो सकते हैं, इसलिए ऑब्जेक्ट बनाने का तर्क दोहराया जाएगा।
• इस तथ्य के बावजूद कि हमारी निर्भरताएं स्पष्ट और समझने में आसान हैं, उपयोगकर्ता कोड अप्रभावी है और प्रबंधन करना मुश्किल है। इसलिए, सब कुछ इतना सरल नहीं है। इसके अलावा, कोड एकल जिम्मेदारी के सिद्धांत का उल्लंघन करता है, क्योंकि यह न केवल अपने काम के लिए जिम्मेदार है, बल्कि निर्भर वर्गों में निर्भरता के कार्यान्वयन के लिए भी है।

दूसरी विधि स्पष्ट रूप से पहले की तुलना में बेहतर काम करती है, लेकिन इसके दोष अभी भी हैं। क्या अधिक उपयुक्त समाधान खोजना संभव है? तीसरे तरीके पर विचार करने से पहले, सबसे पहले निर्भरता इंजेक्शन की अवधारणा के बारे में बात करते हैं।

निर्भरता इंजेक्शन क्या है?

निर्भरता इंजेक्शन आश्रित वर्ग के बाहर निर्भरता को संभालने का एक तरीका है जब आश्रित वर्ग को कुछ भी करने की आवश्यकता नहीं होती है।

इस परिभाषा के आधार पर, हमारा पहला समाधान स्पष्ट रूप से निर्भरता इंजेक्शन के विचार का उपयोग नहीं करता है, और दूसरा तरीका यह है कि निर्भर वर्ग निर्भरता प्रदान करने के लिए कुछ भी नहीं करता है। लेकिन हमें अभी भी लगता है कि दूसरा समाधान खराब है। क्यों!

चूंकि निर्भरता इंजेक्शन की परिभाषा कुछ भी नहीं कहती है कि निर्भरता के साथ काम कहाँ होना चाहिए (आश्रित वर्ग के बाहर को छोड़कर), डेवलपर को निर्भरता इंजेक्शन के लिए एक उपयुक्त स्थान चुनना होगा। जैसा कि आप दूसरे उदाहरण से देख सकते हैं, उपयोगकर्ता वर्ग काफी सही जगह नहीं है।

कैसे करें बेहतर? आइए निर्भरता को संभालने का तीसरा तरीका देखें।

तीसरा तरीका: हमारे बजाय किसी और पर निर्भरता को संभालने दें

पहले दृष्टिकोण के अनुसार, आश्रित वर्ग अपनी निर्भरता प्राप्त करने के लिए जिम्मेदार होते हैं, और दूसरे दृष्टिकोण में, हमने निर्भरता के प्रसंस्करण को निर्भर वर्ग से उपयोगकर्ता वर्ग में स्थानांतरित कर दिया। आइए कल्पना करें कि कोई और है जो निर्भरता को संभाल सकता है, जिसके परिणामस्वरूप न तो आश्रित और न ही उपयोगकर्ता वर्ग काम करेंगे। यह विधि आपको सीधे आवेदन में निर्भरता के साथ काम करने की अनुमति देती है।

निर्भरता इंजेक्शन के "स्वच्छ" कार्यान्वयन (मेरी व्यक्तिगत राय में)

निर्भरता को संभालने की जिम्मेदारी एक तीसरे पक्ष के पास है, इसलिए आवेदन का कोई भी हिस्सा उनके साथ बातचीत नहीं करेगा।

निर्भरता इंजेक्शन एक तकनीक, एक रूपरेखा, एक पुस्तकालय, या ऐसा कुछ नहीं है। यह सिर्फ एक विचार है। विचार आश्रित वर्ग के बाहर निर्भरता के साथ काम करने के लिए है (अधिमानतः एक विशेष रूप से आवंटित भाग में)। आप इस विचार को किसी लाइब्रेरी या फ्रेमवर्क का उपयोग किए बिना लागू कर सकते हैं। हालांकि, हम आमतौर पर निर्भरता को लागू करने के लिए रूपरेखाओं की ओर मुड़ते हैं, क्योंकि यह काम को आसान बनाता है और टेम्पलेट कोड लिखने से बचता है।

किसी भी निर्भरता इंजेक्शन ढांचे में दो निहित विशेषताएं हैं। अन्य अतिरिक्त कार्य आपके लिए उपलब्ध हो सकते हैं, लेकिन ये दो कार्य हमेशा मौजूद रहेंगे:

सबसे पहले, ये फ्रेमवर्क उन क्षेत्रों (वस्तुओं) को निर्धारित करने का एक तरीका प्रदान करते हैं जिन्हें लागू किया जाना चाहिए। कुछ फ्रेमवर्क @Inject एनोटेशन का उपयोग करके किसी फ़ील्ड या कंस्ट्रक्टर की @Inject करके ऐसा @Inject हैं, लेकिन अन्य तरीके भी हैं। उदाहरण के लिए, कोइन कार्यान्वयन को निर्धारित करने के लिए कोटलिन की अंतर्निहित भाषा सुविधाओं का उपयोग करता है। Inject मतलब है कि निर्भरता को डीआई ढांचे द्वारा नियंत्रित किया जाना चाहिए। कोड कुछ इस तरह दिखेगा:

 class ClassA { var classB: ClassB @Inject constructor(classB: ClassB){ this.classB = classB } } class ClassB { var classC: ClassC @Inject constructor(classC: ClassC){ this.classC = classC } } class ClassC { @Inject constructor(){ } } 

दूसरे, चौखटे आपको यह निर्धारित करने की अनुमति देते हैं कि प्रत्येक निर्भरता कैसे प्रदान की जाए, और यह एक अलग फ़ाइल (एस) में होता है। लगभग यह इस तरह दिखता है (ध्यान रखें कि यह सिर्फ एक उदाहरण है, और यह फ्रेमवर्क से फ्रेमवर्क तक भिन्न हो सकता है):

 class OurThirdPartyGuy { fun provideClassC(){ return ClassC() //just creating an instance of the object and return it. } fun provideClassB(classC: ClassC){ return ClassB(classC) } fun provideClassA(classB: ClassB){ return ClassA(classB) } } 

इसलिए, जैसा कि आप देख सकते हैं, प्रत्येक फ़ंक्शन एक निर्भरता को संसाधित करने के लिए जिम्मेदार है। इसलिए, अगर हमें एप्लिकेशन में कहीं क्लास का उपयोग करने की आवश्यकता है, तो निम्न होगा: हमारा DI फ्रेमवर्क प्रदान करता है ClassC को कॉल करके कक्षा का एक उदाहरण, इसे प्रदान करने के लिए provideClassB और provideClassB का एक उदाहरण प्राप्त करता है, जिसे प्रदान करने के लिए पास किया provideClassA , और परिणामस्वरूप, provideClassA बनाया जाता है। यह लगभग जादू है। अब आइए तीसरी विधि के फायदे और लाभ की जांच करें।

लाभ

• सब कुछ यथासंभव सरल है। आश्रित वर्ग और निर्भरता प्रदान करने वाला वर्ग दोनों स्पष्ट और सरल हैं।
• कक्षाएं शिथिल युग्मित हैं और अन्य वर्गों द्वारा आसानी से बदली जा सकती हैं। मान लीजिए कि हम ClassC को AssumeClassC से बदलना चाहते हैं, जो AssumeClassC का एक उपवर्ग है। ऐसा करने के लिए, आपको बस प्रदाता कोड को निम्नानुसार बदलना होगा, और जहाँ भी ClassC का उपयोग किया जाता है, नया संस्करण अब स्वचालित रूप से उपयोग किया जाएगा:

 fun provideClassC(){ return AssumeClassC() } 

कृपया ध्यान दें कि एप्लिकेशन के अंदर कोई कोड नहीं बदलता है, केवल प्रदाता विधि। ऐसा लगता है कि कुछ भी सरल और अधिक लचीला नहीं हो सकता है।

• अतुल्य परीक्षण। आप परीक्षण के दौरान निर्भरता को परीक्षण संस्करणों के साथ आसानी से बदल सकते हैं। वास्तव में, जब परीक्षण की बात आती है तो निर्भरता इंजेक्शन आपका मुख्य सहायक होता है।
• कोड संरचना में सुधार, के रूप में आवेदन में निर्भरता प्रसंस्करण के लिए एक अलग स्थान है। नतीजतन, बाकी एप्लिकेशन अपने कार्यों पर विशेष रूप से ध्यान केंद्रित कर सकते हैं और निर्भरता के साथ ओवरलैप नहीं कर सकते हैं।

कमियों

• डीआई फ्रेमवर्क में एक निश्चित प्रवेश सीमा होती है, इसलिए परियोजना टीम को प्रभावी ढंग से उपयोग करने से पहले समय बिताने और उसका अध्ययन करने की आवश्यकता होती है।

निष्कर्ष

• DI के बिना निर्भरता को संभालना संभव है, लेकिन इससे एप्लिकेशन क्रैश हो सकता है।
• DI सिर्फ एक प्रभावी विचार है, जिसके अनुसार आश्रित वर्ग के बाहर निर्भरता को संभालना संभव है।
• आवेदन के कुछ हिस्सों में DI का उपयोग करना सबसे प्रभावी है। इसके लिए कई रूपरेखाएँ योगदान करती हैं।
• DI के लिए फ्रेमवर्क और लाइब्रेरी की आवश्यकता नहीं है, लेकिन वे बहुत मदद कर सकते हैं।

इस लेख में, मैंने निर्भरता इंजेक्शन की अवधारणा के साथ काम करने की मूल बातें समझाने की कोशिश की, और इस विचार का उपयोग करने के कारणों को भी सूचीबद्ध किया। कई और संसाधन हैं जिन्हें आप अपने स्वयं के अनुप्रयोगों में DI का उपयोग करने के बारे में अधिक जानने के लिए खोज सकते हैं। उदाहरण के लिए, हमारे एंड्रॉइड पेशे के पाठ्यक्रम के उन्नत हिस्से में एक अलग खंड इस विषय के लिए समर्पित है।