निर्भरता इंजेक्शन के तत्वमीमांसा

डिपेंडेंसी इंजेक्शन घटक कनेक्टिविटी को कम करने के लिए डिज़ाइन किए गए ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में आमतौर पर इस्तेमाल की जाने वाली तकनीक है। जब सही ढंग से उपयोग किया जाता है, तो इस लक्ष्य को प्राप्त करने के अलावा, यह आपके अनुप्रयोगों में वास्तव में जादुई गुण ला सकता है। किसी भी जादू की तरह, इस तकनीक को मंत्रों के एक सेट के रूप में माना जाता है, न कि एक कठोर वैज्ञानिक ग्रंथ। इससे घटनाओं की गलत व्याख्या होती है और, परिणामस्वरूप, कलाकृतियों का दुरुपयोग होता है। मेरी संपादकीय सामग्री में, मेरा सुझाव है कि पाठक कदम से, संक्षेप में और संक्षेप में, ऑब्जेक्ट-ओरिएंटेड डिज़ाइन की उपयुक्त नींव से तार्किक पथ पर जाएं, जो कि स्वचालित निर्भरता इंजेक्शन के बहुत ही जादू है।

सामग्री हाइपो आईओसी कंटेनर के विकास पर आधारित है, जिसका मैंने पिछले लेख में उल्लेख किया था। लघु कोड उदाहरणों में, मैं छोटे उदाहरण लिखने के लिए रूबी का उपयोग सबसे संक्षिप्त वस्तु-उन्मुख भाषाओं में से एक के रूप में करूँगा। इससे अन्य भाषाओं के डेवलपर्स को समझने में समस्या नहीं होनी चाहिए।

स्तर 1: निर्भरता उलटा सिद्धांत

ऑब्जेक्ट-ओरिएंटेड प्रतिमान में डेवलपर्स को हर दिन वस्तुओं के निर्माण का सामना करना पड़ता है, जो बदले में, अन्य वस्तुओं पर निर्भर हो सकता है। यह एक निर्भरता ग्राफ की ओर जाता है। मान लें कि हम फ़ॉर्म के ऑब्जेक्ट मॉडल के साथ काम कर रहे हैं:

- कुछ बिलिंग सेवा (इनवॉयसप्रोसेसर) और एक अधिसूचना सेवा (अधिसूचना सेवा)। इनवॉइस प्रोसेसिंग सेवा कुछ शर्तों के पूरा होने पर सूचनाएं भेजती है, हम इस तर्क को दायरे से बाहर करेंगे। सिद्धांत रूप में, यह मॉडल पहले से ही अच्छा है कि व्यक्तिगत घटक विभिन्न जिम्मेदारियों के लिए जिम्मेदार हैं। समस्या यह है कि हम इन निर्भरताओं को कैसे लागू करते हैं। एक सामान्य गलती एक निर्भरता को प्रारंभ करना है जहां इस निर्भरता का उपयोग किया जाता है:

class InvoiceProcessor def process(invoice) #      notificationService = NotificationService.new notificationService.notify(invoice.owner) end end 

यह इस तथ्य के मद्देनजर एक गलती है कि हमें तार्किक रूप से स्वतंत्र वस्तुओं (हाई कपलिंग) की उच्च कनेक्टिविटी मिलती है। यह एकल जिम्मेदारी सिद्धांत का उल्लंघन होता है - एक आश्रित वस्तु, अपनी तत्काल जिम्मेदारियों के अलावा, अपनी निर्भरता को शुरू करना चाहिए; और यह भी "पता" निर्भरता निर्माता का इंटरफ़ेस, जो परिवर्तन के लिए एक अतिरिक्त कारण होगा ( "बदलने का कारण", आर। मार्टिन )। इस प्रकार की निर्भरता को पास करना अधिक सही है, यह निर्भर वस्तु के बाहर आरम्भिक है:

 class InvoiceProcessor def initialize(notificationService) @notificationService = notificationService end def process(invoice) @notificationService.notify(invoice.owner) end end notificationService = NotificationService.new invoiceProcessor = InvoiceProcessor.new(notificationService) 

यह दृष्टिकोण निर्भरता उलटा सिद्धांत के अनुरूप है। अब हम एक ऑब्जेक्ट को संदेश भेजने वाले इंटरफ़ेस के साथ स्थानांतरित कर रहे हैं - अधिसूचना सेवा ऑब्जेक्ट का निर्माण करने के लिए बिलिंग सेवा के लिए "पता" की कोई आवश्यकता नहीं है। चालान प्रसंस्करण सेवा के लिए इकाई परीक्षण लिखते समय, डेवलपर के पास इस बात की पहेली नहीं होती है कि अधिसूचना सेवा इंटरफ़ेस के कार्यान्वयन को स्टब से कैसे बदला जाए। गतिशील टाइपिंग वाली भाषाओं में, जैसे कि रूबी, आप किसी भी ऑब्जेक्ट को अधिसूचित विधि से पूरा कर सकते हैं; स्थिर टाइपिंग के साथ, जैसे कि C # / Java, आप INotificationService इंटरफ़ेस का उपयोग कर सकते हैं, जिसके लिए Mock बनाना आसान है। निर्भरता के मुद्दे के बारे में विस्तार से खुलासा किया गया था अलेक्जेंडर Byndyu ने हाल ही में अपनी 10 वीं वर्षगांठ मनाई एक लेख में !

स्तर 2: संबंधित वस्तुओं की रजिस्ट्री

निर्भरता उलटा के सिद्धांत का उपयोग करना जटिल अभ्यास नहीं लगता है। लेकिन समय के साथ, वस्तुओं और रिश्तों की संख्या में वृद्धि के कारण, नई चुनौतियां सामने आती हैं। NotificationService का उपयोग इनवॉयसप्रोसेसर के अलावा अन्य सेवाओं द्वारा किया जा सकता है। इसके अलावा, वह खुद अन्य सेवाओं पर निर्भर हो सकता है, जो बदले में, तीसरे पर निर्भर करते हैं, आदि। इसके अलावा, कुछ घटकों का उपयोग हमेशा एक प्रति में नहीं किया जा सकता है। मुख्य कार्य प्रश्न का उत्तर ढूंढना है - "जब निर्भरता बनाने के लिए?"।
इस समस्या को हल करने के लिए, आप निर्भरता के साहचर्य सरणी के आधार पर एक समाधान बनाने की कोशिश कर सकते हैं। उनके काम का एक उदाहरण इंटरफ़ेस इस तरह दिख सकता है:

 registry.add(InvoiceProcessor) .depends_on(NotificationService) registry.add(NotificationService) .depends_on(ServiceX) invoiceProcessor = registry.resolve(InvoiceProcessor) invoiceProcessor.process(invoice) 

व्यवहार में इसे लागू करना मुश्किल नहीं है:


हर बार जब कंटेनर.आर्सोल्व () कहा जाता है, तो हम कारखाने में बदल जाएंगे, जो निर्भरता के उदाहरण पैदा करेगा, रजिस्ट्री में वर्णित निर्भरता ग्राफ को दरकिनार करते हुए। `कंटेनर.ट्रेस (इनवॉयसप्रोसेसर)` के मामले में, निम्नलिखित निष्पादित किया जाएगा:

1. factory.resolve (इनवॉयसप्रोसेसर) - कारखाना रजिस्टर में इनवॉयसप्रोसेसर निर्भरता के लिए पूछता है, एक अधिसूचना सेवा प्राप्त करता है, जिसे भी इकट्ठा करने की आवश्यकता होती है।
2. factory.resolve (NotificationService) - कारखाना रजिस्टर में NotificationService निर्भरता का अनुरोध करता है, ServiceX प्राप्त करता है, जिसे भी इकट्ठा करने की आवश्यकता होती है।
3. factory.resolve (ServiceX) - कोई निर्भरता नहीं है, बनाएं, चरण 1 पर कॉल स्टैक पर लौटें, इनवॉइसप्रोसेसर का एक इकट्ठे ऑब्जेक्ट प्राप्त करें।

प्रत्येक घटक कई अन्य पर निर्भर हो सकता है, इसलिए स्पष्ट प्रश्न "परिणामी निर्भरता उदाहरणों के साथ डिजाइनर मापदंडों का सही ढंग से मिलान कैसे करें"। एक उदाहरण:

 class InvoiceProcessor def initialize(notificationService, paymentService) # ... end end 

स्थिर टाइपिंग वाली भाषाओं में, पैरामीटर प्रकार एक चयनकर्ता के रूप में काम कर सकता है:

 class InvoiceProcessor { constructor(notificationService: NotificationService, paymentService: PaymentService) { // ... } } 

रूबी के भीतर, आप कन्वेंशन का उपयोग कर सकते हैं - बस स्नेक_केस प्रारूप में टाइप नाम का उपयोग करें, यह अपेक्षित पैरामीटर नाम होगा।

स्तर 3: निर्भरता जीवनकाल प्रबंधन

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


और तार्किक समाधान घटकों के उदाहरण प्राप्त करने के लिए रणनीतियों ( रणनीति, GoF ) के एक सेट का उपयोग करना है। कंटेनर :: रेजोल्यूशन को कॉल करते समय अब ​​हम हमेशा नए उदाहरण नहीं बनाते हैं, इसलिए फैक्ट्री को रिज़ॉल्वर का नाम देना उचित है। कृपया ध्यान दें कि कंटेनर :: रजिस्टर विधि में एक नया पैरामीटर है - life_time (जीवनकाल)। यह पैरामीटर वैकल्पिक है - डिफ़ॉल्ट रूप से इसका मूल्य "क्षणिक" (क्षणिक) है, जो पहले से लागू व्यवहार से मेल खाता है। सिंगलटन रणनीति भी स्पष्ट है - इसके उपयोग के साथ घटक का केवल एक उदाहरण बनाया जाता है, जो हर बार वापस आ जाएगा।
स्कोप थोड़ी अधिक जटिल रणनीति है। "क्षणिक रास्तों" और "कुंवारे" के बजाय, अक्सर बीच में कुछ का उपयोग करना आवश्यक होता है - एक घटक जो किसी अन्य घटक के जीवन भर में मौजूद होता है। एक समान उदाहरण एक वेब एप्लिकेशन अनुरोध ऑब्जेक्ट हो सकता है, जो कि ऐसी वस्तुओं के अस्तित्व का संदर्भ है, उदाहरण के लिए, HTTP पैरामीटर, डेटाबेस कनेक्शन, मॉडल समुच्चय। अनुरोध के जीवन भर, हम इन निर्भरताओं को इकट्ठा करते हैं और उपयोग करते हैं, और इसके विनाश के बाद, हम उम्मीद करते हैं कि वे सभी भी नष्ट हो जाएंगे। इस तरह की कार्यक्षमता को लागू करने के लिए, एक काफी जटिल, बंद वस्तु संरचना विकसित करना आवश्यक होगा:


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

अनुक्रम आरेख सत्र घटक के जीवन चक्र को दर्शाता है, जो अनुरोध घटक जीवनकाल के लिए बंधा हुआ है:



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

स्तर 4: निर्भरता इंजेक्शन

अब तक, मैंने निर्भरता की रजिस्ट्री का निर्धारण करने के तरीके के बारे में बात की थी, और फिर कैसे बने संबंधों के ग्राफ के अनुसार घटकों को बनाने और नष्ट करने के लिए। और इसके लिए क्या है? मान लें कि हम इसका उपयोग रूबी ऑन रेल्स के हिस्से के रूप में करते हैं:

 class InvoiceController < ApplicationController def pay(params) invoice_repository = registry.resolve(InvoiceRepository) invoice_processor = registry.resolve(InvoiceProcessor) invoice = invoice_repository.find(params[:id]) invoice_processor.pay(invoice) end end 

इस तरह से लिखा जाने वाला कोड अधिक पठनीय, परीक्षण योग्य या लचीला नहीं होगा। हम इसके निर्माता के माध्यम से नियंत्रक निर्भरता को इंजेक्ट करने के लिए "बल" रेल नहीं कर सकते, यह फ्रेमवर्क द्वारा प्रदान नहीं किया गया है। लेकिन, उदाहरण के लिए, ASP.NET MVC में यह एक बुनियादी स्तर पर लागू किया जाता है। स्वचालित निर्भरता रिज़ॉल्यूशन तंत्र का उपयोग करने के लिए सबसे बाहर निकलने के लिए, आपको नियंत्रण के उलटा (IoC, नियंत्रण के व्युत्क्रम) तकनीक को लागू करने की आवश्यकता है। यह एक दृष्टिकोण है जिसमें निर्भरता को हल करने की जिम्मेदारी आवेदन कोड के दायरे से परे जाती है और रूपरेखा के साथ टिकी हुई है। एक उदाहरण पर विचार करें।
कल्पना कीजिए कि हम खरोंच से रेल जैसा कुछ डिजाइन कर रहे हैं। हम निम्नलिखित योजना को लागू करते हैं:


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

 class App #   - ,      . def initialize @container = Container.new @container .register(Controller) .using_lifetime(:transient) # ,     @container .register(InvoiceService) .using_lifetime(:singleton) # ,     @container .register(Router) .using_lifetime(:singleton) #  end #     -     , #      . def call(env) router = @container.resolve(Router) router.handle(env.path, env.method, env.params) end end 

किसी भी आवेदन में एक प्रवेश बिंदु होता है, उदाहरण के लिए, मुख्य विधि। इस उदाहरण में, प्रविष्टि बिंदु कॉल विधि है। इस पद्धति का उद्देश्य आवक अनुरोधों को संसाधित करने के लिए राउटर को कॉल करना है। प्रवेश बिंदु को सीधे कंटेनर को कॉल करने के लिए एकमात्र स्थान होना चाहिए - उस पल से कंटेनर को सड़क के किनारे जाना चाहिए, बाद के सभी जादू "हुड के नीचे" होने चाहिए। ऐसी वास्तुकला के भीतर नियंत्रक का कार्यान्वयन वास्तव में असामान्य दिखता है। इस तथ्य के बावजूद कि हम इसे स्पष्ट रूप से नहीं बताते हैं, इसका एक पैरामीटर पैरामीटर है:

 class Controller #   . #    . def initialize(invoice_service) @invoice_service = invoice_service end def create_invoice(params) @invoice_service.create(params) end end 

पर्यावरण "समझता है" कैसे नियंत्रक उदाहरण बनाने के लिए। यह वेब अनुप्रयोग के दिल में एम्बेडेड IoC कंटेनर द्वारा प्रदान की गई निर्भरता इंजेक्शन तंत्र के लिए धन्यवाद संभव है। नियंत्रक के निर्माता में, अब आप वह सब कुछ सूचीबद्ध कर सकते हैं जो इसके संचालन के लिए आवश्यक है। मुख्य बात यह है कि संबंधित घटक कंटेनर में पंजीकृत हैं। अब राउटर कार्यान्वयन की ओर मुड़ते हैं:

 class Router #         -  #      #     . def initialize(controller) @controller = controller end def handle(path, method, params) #  ""- if path == '/invoices' && method == 'POST' @controller.create(params) end end end 

ध्यान दें कि राउटर नियंत्रक पर निर्भर है। यदि हम निर्भरता सेटिंग्स को याद करते हैं, तो नियंत्रक एक अल्पकालिक घटक है, और राउटर एक निरंतर अकेला है। यह कैसे हो सकता है? इसका उत्तर यह है कि घटक संबंधित वर्गों के उदाहरण नहीं हैं, क्योंकि यह बाहरी रूप से दिखता है। वास्तव में, ये फैक्ट्री विधि ( फैक्ट्री मेथड, गोफ ) उदाहरण के साथ प्रॉक्सी ऑब्जेक्ट ( प्रॉक्सी, गोएफ ) हैं; वे असाइन की गई रणनीति के अनुसार घटक का एक उदाहरण लौटाते हैं। चूंकि नियंत्रक को "क्षणिक" के रूप में पंजीकृत किया गया है, इसलिए राउटर हमेशा अपने नए उदाहरण के साथ ही एक्सेस करेगा। अनुक्रम आरेख कार्य का एक अनुमानित तंत्र दिखाता है:


यानी निर्भरता प्रबंधन के अलावा, आईओसी कंटेनर पर आधारित एक अच्छा ढांचा भी घटक जीवनकाल के सही प्रबंधन के लिए जिम्मेदारी लेता है।

निष्कर्ष

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