निर्भरता इंजेक्शन: क्या मुझे एक रूपरेखा का उपयोग करना चाहिए?


24

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

जब किसी वस्तु को कई स्थानों पर बनाना होता है, तो उत्पादन का उदाहरण बनाने के लिए हमारे पास बस एक फ़ंक्शन (कभी-कभी उस वस्तु का एक वर्ग तरीका) होता है। जब भी हमें उस वस्तु की आवश्यकता होती है, तो यह फ़ंक्शन कहा जाता था।

परीक्षणों में, हमने एक ही काम किया: यदि कई बार हमें किसी वस्तु का 'परीक्षण-संस्करण' बनाने की आवश्यकता होती है (अर्थात, नकली वस्तुओं द्वारा समर्थित वास्तविक उदाहरण), हमारे पास इस 'परीक्षण-संस्करण' को बनाने के लिए एक समारोह था। परीक्षण में उपयोग किया जाना है।

जैसा कि मैंने कहा, आम तौर पर यह ठीक काम करता था।

मैं अब एक नई जावा परियोजना में प्रवेश कर रहा हूं, और हम यह तय कर रहे हैं कि क्या डीआई फ्रेमवर्क का उपयोग करना है, या डीआई मैन्युअल रूप से करना है (पिछली परियोजना की तरह)।

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

संपादित करें: मैं इस प्रश्न को भी जोड़ना चाहूंगा: क्या आपने किसी ऐसे 'व्यावसायिक स्तर' प्रोजेक्ट को देखा है, जो बिना किसी फ्रेमवर्क के DI को मैन्युअल रूप से करता है?


मेरे उत्तर के पास। दोनों तरीके संगत हैं। आप फ्रेम के लिए नरम निर्भरता इंजेक्शन छोड़ सकते हैं और महत्वपूर्ण घटकों के लिए अपने कारखाने रख सकते हैं। मॉडल या व्यवसाय से संबंधित घटक।
Laiv

4
मुझे लगता है कि आप पहले से ही जाँच कर चुके हैं, सिर्फ इस मामले में कि आपको DI के लिए रूपरेखा की आवश्यकता क्यों
लािव

जवाबों:


19

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

पृष्ठभूमि

वर्षों पहले, ऐसी अमूर्तता के लिए हमें विभिन्न कॉन्फिग फाइल ( डिक्लेक्टिव प्रोग्रामिंग ) लिखने की आवश्यकता थी । यह LOC की संख्या को काफी हद तक कम होते देखना शानदार था, लेकिन जब LOCS में कमी हुई, तो कॉन्फिग फाइलों की संख्या थोड़ी बढ़ गई। मध्यम या छोटी परियोजनाओं के लिए यह एक समस्या नहीं थी, लेकिन बड़ी परियोजनाओं के लिए, कोड की "असेंबली" होने के लिए कोड और XML विवरणकों के बीच 50% बिखरे हुए थे ... फिर भी, मुख्य समस्या सबसे बड़ी थी प्रतिमान। यह काफी अनम्य था क्योंकि विवरणकर्ताओं ने अनुकूलन के लिए बहुत कम जगह छोड़ी थी।

प्रतिमान उत्तरोत्तर विन्यास पर अधिवेशन की ओर स्थानांतरित हो गया , जो एनोटेशन या विशेषताओं के लिए फ़ाइलों को कॉन्फ़िगर करता है। यह हमारे कोड को क्लीनर और सरल रखता है जबकि हमें वह लचीलापन प्रदान करता है जो XML नहीं कर सकता था।

शायद, यह इस बात का सबसे महत्वपूर्ण अंतर है कि आप अब तक कैसे काम कर रहे थे। कम कोड और अधिक जादू।

नीचे की ओर...

कॉन्फ़िगरेशन पर कन्वेंशन अमूर्तता को इतना भारी बना देता है कि आप मुश्किल से जानते हैं कि यह कैसे काम करता है। कभी-कभी जादू लगता है और यहां एक और कमी आती है। एक बार काम करने के बाद, कई डेवलपर्स इस बात की परवाह नहीं करते हैं कि यह कैसे काम करता है।

यह उन लोगों के लिए एक बाधा है जिन्होंने DI कंटेनरों के साथ DI सीखा। वे पूरी तरह से डिजाइन पैटर्न, अच्छी प्रथाओं और कंटेनर द्वारा अमूर्त सिद्धांतों की प्रासंगिकता को नहीं समझते हैं। मैंने डेवलपर्स से पूछा है कि क्या वे डीआई और उसके फायदों से परिचित थे और उन्होंने उत्तर दिया: - हां, मैंने स्प्रिंग आईओसी का उपयोग किया है । (इसका क्या मतलब है?)

इनमें से प्रत्येक "कमियां" से सहमत या नहीं हो सकता है। मेरी विनम्र राय में, यह जानना आवश्यक है कि आपके प्रोजेक्ट में क्या हो रहा है। अन्यथा, हमें इसकी पूरी समझ नहीं है। यह भी जानना है कि DI क्या है और इसे कैसे लागू किया जाए, इस पर विचार करने के लिए एक विचार है।

सकारात्मक स्थिति की ओर...

एक शब्द उत्पादकता । फ्रेमवर्क हमें इस बात पर ध्यान केंद्रित करते हैं कि वास्तव में क्या मायने रखता है। अनुप्रयोग का व्यवसाय।

कमियों के बावजूद, हम में से कई के लिए (जो काम समय सीमा और लागत से वातानुकूलित है), ये उपकरण एक अमूल्य संसाधन हैं। मेरी राय में, डि कंटेनर को लागू करने के पक्ष में यह हमारा मुख्य तर्क होना चाहिए। उत्पादकता

परिक्षण

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

सही लुभावना लगता है? सावधान रहे! जाल में मत पड़ो !!

सुझाव

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

इस प्रथा के बारे में:

DI कंटेनरों का उपयोग कब करें

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

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

अंत में, अगर हम जावा की बात कर रहे हैं, तो मैं सबसे पहले JSR330 - डिपेंडेंसी इंजेक्शन पर एक नज़र डालूंगा

सारांश

लाभ :

  • लागत में कटौती और समय की बचत। उत्पादकता।
  • घटकों की एक छोटी संख्या।
  • कोड सरल और साफ हो जाता है।

कमियां :

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

शुद्ध डि के साथ अंतर :

  • कम कोड और अधिक विन्यास फाइल या एनोटेशन।

1
"ये फ्रेमवर्क आपको यूनिट टेस्ट या अखंडता परीक्षण करने के लिए निजी नहीं करते हैं, इसलिए आपको परीक्षण की चिंता नहीं है।" वास्तव में इसका क्या मतलब है? शब्दांकन मुझे लगता है कि यह एक टाइपो है, लेकिन मुझे इसे डिकोड करने में परेशानी हो रही है।
कैंडिड_ऑरेंज

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

यदि आप इसका मतलब समझते हैं: "ये फ्रेमवर्क आपको यूनिट परीक्षण या अखंडता परीक्षण करने से नहीं रोकते हैं, तो क्या आप इस बात की चिंता नहीं करते हैं कि वे परीक्षण को कैसे प्रभावित करते हैं"
कैंडिड_ऑरेंज

Srry। मैं यह कहने की कोशिश करता हूं कि वह इन रूपरेखाओं के साथ अपने कोड का भी परीक्षण कर सकेंगे। अमूर्तता के बावजूद, परीक्षण अभी भी उल्लेखनीय है। मेरे उत्तर को संपादित करने के लिए स्वतंत्र महसूस करें। जैसा कि आप देख रहे हैं कि मेरी अंग्रेजी अभी भी सभ्य है :-)
Laiv

1
ध्यान दें कि Dagger2 DI को थोड़ा अलग करता है। गोंद कोड सामान्य, पठनीय जावा स्रोतों के रूप में संकलित समय पर उत्पन्न होता है, इसलिए यह पालन करना बहुत सरल है कि रनटाइम जादू से निपटने के लिए चीजों को एक साथ कैसे जोड़ा जाता है।
थोरबजोरन रावन एंडरसन

10

मेरे अनुभव में, एक निर्भरता इंजेक्शन ढांचा कई मुद्दों की ओर जाता है। कुछ मुद्दों की रूपरेखा और टूलींग पर निर्भर करेगा। ऐसी प्रथाएँ हो सकती हैं जो मुद्दों को कम करती हैं। लेकिन ये मुद्दे हैं जो मैंने मारा है।

गैर-वैश्विक वस्तुएँ

कुछ मामलों में, आप एक वैश्विक ऑब्जेक्ट को इंजेक्ट करना चाहते हैं: एक ऑब्जेक्ट जो आपके रनिंग एप्लिकेशन में केवल एक उदाहरण होगा। यह ए MarkdownToHtmlRendererer, ए DatabaseConnectionPool, आपके एपीआई सर्वर के लिए पता आदि हो सकता है । इन मामलों के लिए, निर्भरता इंजेक्शन फ्रेमवर्क बहुत सरलता से काम करते हैं, आप बस अपने कंस्ट्रक्टर में आवश्यक निर्भरता जोड़ते हैं और आपको यह मिल गया है।

लेकिन उन वस्तुओं के बारे में जो वैश्विक नहीं हैं? यदि आपको वर्तमान अनुरोध के लिए उपयोगकर्ता की आवश्यकता है तो क्या होगा? यदि आपको वर्तमान में सक्रिय डेटाबेस लेनदेन की आवश्यकता है तो क्या होगा? यदि आपको div के अनुरूप HTML तत्व की आवश्यकता होती है, जिसमें एक ऐसा फ़ॉर्म होता है जिसमें एक टेक्स्ट बॉक्स होता है जिसने किसी ईवेंट को निकाल दिया है?

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

पुस्तकालय

अक्सर आप पुन: प्रयोज्य कोड की एक लाइब्रेरी चाहते होंगे। इसमें उस कोड से ऑब्जेक्ट का निर्माण करने के निर्देश भी शामिल होंगे। यदि आप एक निर्भरता इंजेक्शन ढांचे का उपयोग करते हैं, तो इसमें आम तौर पर बाध्यकारी नियम शामिल होंगे। यदि आप पुस्तकालय का उपयोग करना चाहते हैं, तो आप उनके बाध्यकारी नियमों को अपने साथ जोड़ते हैं।

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

छिपी हुई जटिलता

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

आईडीई समर्थन

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

निष्कर्ष

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


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

@ रुबरडैक, मेरे मामले में, मैंने एक बड़ी कंपनी के लिए काम किया, जिसमें बड़ी संख्या में जावा प्रोजेक्ट्स हैं, जो एक ही डिपेंडेंसी इंजेक्शन फ्रेमवर्क पर मानकीकृत हैं। उस बिंदु पर यह कुछ टीमों के लिए एक पुस्तकालय निर्यात करने के लिए लुभावना हो जाता है जो उम्मीद करता है कि डीआई फ्रेमवर्क द्वारा एक साथ रखा जाएगा, बल्कि तब एक समझदार बाहरी इंटरफ़ेस प्रदान किया जाएगा।
विंस्टन एवर्ट

यह दुर्भाग्यपूर्ण है @instonEwert। मेरे लिए संदर्भ में भरने के लिए धन्यवाद।
रबरडैक

यह IDE भाग के लिए बहुत अच्छा होगा, इंजेक्शन के ढांचे के रनटाइम बाइंडिंग के साथ मैनुअल इंजेक्शन के टाइम टाइप बाइंडिंग के विपरीत। कंपाइलर भूल गए इंजेक्शन को मैनुअल होने पर रोकता है।
बसिलेव्स

IntelliJ CDI (जावा EE मानक DI) को समझता है
Thorbjørn Ravn Andersen

3

क्या जावा + निर्भरता इंजेक्शन = ढांचे की आवश्यकता है?

नहीं।

डीआई फ्रेमवर्क मुझे क्या खरीदता है?

ऐसी भाषा में ऑब्जेक्ट निर्माण जो जावा नहीं है।


अगर फैक्ट्री के तरीके आपकी आवश्यकताओं के लिए काफी अच्छे हैं, तो आप डीआई को जावा में पूरी तरह से 100% प्रामाणिक पोजो जावा में पूरी तरह से मुक्त कर सकते हैं। यदि आपकी जरूरतें इससे परे हैं तो आपके पास अन्य विकल्प हैं।

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

कई रचनात्मक पैटर्न हैं जो चार के गिरोह के बाद सामने आए। जोश बलोच बिल्डर जावा के नामांकित मापदंडों की कमी के आसपास एक अद्भुत हैक है। इसके अलावा iDSL बिल्डर हैं जो बहुत अधिक लचीलापन प्रदान करते हैं। लेकिन इनमें से प्रत्येक महत्वपूर्ण काम और बॉयलरप्लेट का प्रतिनिधित्व करते हैं।

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

इससे पहले कि आप डीआई फ्रेमवर्क की शक्ति के साथ बहुत अधिक आसक्त हो जाएं और कुछ अन्य फ्रेमवर्क की जांच करें जो आपको क्षमता प्रदान करते हैं जो आपको अन्यथा लगता है कि आपको डीआई फ्रेमवर्क की आवश्यकता हो सकती है। कई लोग साधारण डीआई से आगे निकल गए हैं । पर विचार करें: लंबोक , AspectJ , और slf4J । प्रत्येक डीआई फ्रेमवर्क के साथ ओवरलैप होते हैं, लेकिन प्रत्येक अपने आप ठीक होता है।

यदि परीक्षण वास्तव में इसके पीछे की प्रेरणा शक्ति है, तो कृपया ध्यान रखें: DI DI फ्रेमवर्क को आपके जीवन में उतारना शुरू करने से पहले jUnit (वास्तव में कोई xUnit) और Mockito (वास्तव में कोई भी नकली)

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


PowerMock ने इनमें से कुछ मामलों को हल किया है। कम से कम यह आपको स्टैटिक्स का
मज़ाक उड़ाने देता है

भावहीन। यदि आप DI ठीक से कर रहे हैं, तो एक के लिए एक IoC कंटेनर फ्रेमवर्क को स्वैप करना अपेक्षाकृत सरल होना चाहिए। उन एनोटेशन को अपने कोड से बाहर रखें और आप ठीक हो जाएंगे। मूल रूप से, सर्विस लोकेटर के रूप में कंटेनर का उपयोग करने के बजाय DI करने के लिए IoC कंटेनर का उपयोग करें।
रबरडैक

@ रबरडाक सही। कई DI चौखटे के नीचे अपने कोड आधार का लगातार परीक्षण और रखरखाव करने का संक्षिप्त तरीका क्या आपको पता है कि "आप ठीक से DI कर रहे हैं" यह जांचने का एक सरल विश्वसनीय तरीका है? यहां तक ​​कि अगर मैं जावा में जावा के अलावा कुछ भी नहीं इस्तेमाल करता हूं, अगर महत्वपूर्ण प्रयास एक्सएमएल बनाने में चला गया है, तो यह अभी भी एक साधारण स्वैप नहीं है जब XML आईओसी कंटेनर पर निर्भर है।
कैंडिड_ऑरेंज

@CandiedOrange मैं एक रिश्तेदार शब्द के रूप में "सरल" का उपयोग कर रहा हूं। चीजों की भव्य योजना में, एक रचना की जड़ को दूसरे के साथ प्रतिस्थापित करना अधिक कठिन काम नहीं है। कुछ दिनों के काम में सबसे ऊपर है। यह सुनिश्चित करने के लिए कि आप DI को ठीक से कर रहे हैं, कोड कोड क्या हैं।
रबरडैक

2
@RubberDuck सबसे "रचना की जड़ें" मैंने देखा है कि कोड की लगभग 5 पंक्तियाँ मुख्य हैं। तो नहीं। अत्यधिक कठिन कार्य नहीं है। यह मालिकाना सामान है जो उन लाइनों से बच जाता है, जिनके खिलाफ मैं चेतावनी दे रहा हूं। आप इसे "डीआई को ठीक से करना" कहते हैं। मैं पूछ रहा हूं कि क्या आप एक कोड समीक्षा में किसी समस्या को साबित करने के लिए उपयोग करेंगे। या आप सिर्फ "मेह" कहेंगे?
कैंडिड_ऑरेंज

2

कक्षाएं बनाना और उन्हें निर्भरता प्रदान करना मॉडलिंग प्रक्रिया, मज़ेदार भागों का हिस्सा है। यही कारण है कि अधिकांश प्रोग्रामर प्रोग्रामिंग का आनंद लेते हैं।

निर्णय लेना, किस कार्यान्वयन का उपयोग किया जाएगा और कक्षाओं का निर्माण कैसे किया जाता है यह एक ऐसी चीज है जिसे किसी भी तरह लागू करना होगा और एप्लिकेशन कॉन्फ़िगरेशन का हिस्सा है।

कारखानों को मैन्युअल रूप से लिखना एक थकाऊ काम है। डीआई फ्रेमवर्क स्वचालित रूप से निर्भरता को हल करके आसान बनाते हैं जो हल हो सकते हैं और उन लोगों के लिए कॉन्फ़िगरेशन की आवश्यकता होती है जो नहीं हो सकते हैं।

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

लेकिन डीआई फ्रेमवर्क के साथ भी, आपके पास एक केंद्रीय स्थान हो सकता है, जैसे कि ऑब्जेक्ट ग्राफ निर्माण कॉन्फ़िगरेशन (अब से ओजीसीसी), और अगर कोई वर्ग अस्पष्ट निर्भरता पर निर्भर करता है, तो आप बस ओजीसीसी में देख सकते हैं और देख सकते हैं कि एक विशिष्ट वर्ग का निर्माण कैसे किया जा रहा है। ठीक वहीं।

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

यदि आपने हमेशा उन प्रोजेक्ट्स पर काम किया है जो DI फ्रेमवर्क पर निर्भर थे, तो आप वास्तव में केवल यही जानते होंगे और जब आप एक क्लास का कॉन्फ़िगरेशन देखना चाहते थे, तो आप हमेशा OGCC में देखेंगे और यह भी देखने की कोशिश नहीं करेंगे कि कंस्ट्रक्टर का उपयोग कैसे किया जाता है , क्योंकि आपको पता होगा कि निर्भरताएं वैसे भी स्वचालित रूप से पूरी हो जाती हैं।

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

अंत में यह सबसे अधिक संभावना है कि आपकी प्राथमिकताएं क्या हैं और आप क्या त्याग करने के लिए तैयार हैं (या तो कारखानों या पारदर्शिता लिखने के लिए)।


व्यक्तिगत अनुभव (चेतावनी: व्यक्तिपरक)

PHP डेवलपर के रूप में बोलते हुए, हालांकि मुझे DI चौखटे के पीछे का विचार पसंद है, मैंने केवल एक बार ही उनका उपयोग किया है। ऐसा तब था जब मैं जिस टीम के साथ काम कर रहा था वह बहुत तेज़ी से एक एप्लिकेशन को तैनात करने वाली थी और हम समय लेखन कारखानों को खो नहीं सकते थे। तो हमने बस एक DI फ्रेमवर्क उठाया, इसे कॉन्फ़िगर किया, और यह काम किया, किसी तरह

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


2

व्यक्तिगत रूप से मैं DI-कंटेनरों का उपयोग नहीं करता और उन्हें पसंद नहीं करता। मेरे पास इसके लिए कुछ और कारण हैं।

आमतौर पर यह एक स्थिर निर्भरता है। तो यह सिर्फ एक सेवा लोकेटर है जिसमें इसकी सभी कमियां हैं। फिर, स्थिर निर्भरता की प्रकृति के कारण, वे छिपे हुए हैं। आपको उनसे निपटने की आवश्यकता नहीं है, वे किसी तरह पहले से ही वहां मौजूद हैं, और यह खतरनाक है, क्योंकि आप उन्हें नियंत्रित करना बंद कर देते हैं।

यह OOP सिद्धांतों को तोड़ता है , जैसे सामंजस्य और डेविड वेस्ट की लेगो-ईंट ऑब्जेक्ट रूपक।

इसलिए पूरे ऑब्जेक्ट को प्रोग्राम के एंट्री पॉइंट के जितना करीब हो सके उतना ही जाने का रास्ता है।


1

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

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

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

उन्होंने कहा, डीआई-फ्रेमवर्क की कोई आवश्यकता नहीं है।

लेकिन फिर भी आप एक फ्रेमवर्क का उपयोग क्यों करना चाहते हैं?

मैं) बॉयलरप्लेट कोड से बचें

यदि आपकी परियोजना को एक आकार मिलता है, जहां आपको बार-बार लेखन कारखानों (और अस्थिरता) का दर्द महसूस होता है, तो आपको एक DI- फ्रेमवर्क का उपयोग करना चाहिए

II) प्रोग्रामिंग के लिए निर्णायक दृष्टिकोण

जब जावा एक बार एक्सएमएल के साथ प्रोग्रामिंग कर रहा था तो अब यह है: एनोटेशन के साथ फेयरडस्ट छिड़कना और जादू होता है

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


tl; डॉ

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


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

1
मुझे लगता है कि यह जानना हमेशा सही होता है कि हुड के नीचे सामान कैसे काम करता है। लेकिन यह आपको नहीं जानना चाहिए। मुझे लगता है कि स्प्रिंग ईजी के लिए विक्रय बिंदु यह है कि यह सिर्फ काम करता है। और हाँ, आप बिलकुल सही हैं, कि फ्रेमवर्क का उपयोग करने के बारे में सूचित निर्णय लेने के लिए, आपके पास कुछ ज्ञान होना आवश्यक है। लेकिन मैं अक्सर उन लोगों के लिए अविश्वास का एक पैटर्न देखता हूं जो स्वयं के रूप में एक ही निशान नहीं हैं, हालांकि आपके मामले में नहीं, जहां विश्वास है, केवल वही है जिसने मैनुअल शिकार का अनुभव किया है उसे सुपरमार्केट में जाने की अनुमति है।
थॉमस जंक

सौभाग्य से, इन दिनों हमें जावा के लिए स्प्रिंग या DI फ्रेमवर्क की भी आवश्यकता नहीं है। हमें पहले से ही JSR330 मिला हुआ है, जिसे दुखद रूप से अनदेखा किया गया है (कम से कम मैंने इसे लागू करने वाला कोई प्रोजेक्ट नहीं देखा था)। इसलिए, लोगों के पास अभी भी समय है कि उनके निशान
जीतें

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

1
जवाब इतना कम बदला !!! कुछ भी नहीं है कि आप चिंता करना चाहिए :-)। संदेश और तर्क समान हैं। मैं चाहता था कि आपका उत्तर ऐसा ही हो। मुझे लगता है कि यह सिर्फ आपको उद्धरणों में से एक को निकालने के लिए लिया गया है।
Laiv

0

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


0

हां, जावा में काम करते समय, मैं एक डीआई फ्रेमवर्क की सिफारिश करूंगा। इसके लिए कुछ कारण हैं:

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

  • जावा एनोटेशन बेहद उपयोगी होते हैं और निर्भरता को कॉन्फ़िगर करने का एक उत्कृष्ट तरीका प्रदान करते हैं

  • जब आप अजगर में उपयोग किए जाते हैं, तो उसकी तुलना में जावा ऑब्जेक्ट निर्माण अत्यधिक क्रिया है; यहां एक फ्रेमवर्क का उपयोग करने से यह एक गतिशील भाषा में अधिक काम बचाता है।

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


0

यदि आपका प्रोजेक्ट काफी छोटा है और आपके पास DI-फ्रेमवर्क के साथ ज्यादा अनुभव नहीं है, तो मैं फ्रेमवर्क का उपयोग नहीं करने और मैन्युअल रूप से डाय करने की सिफारिश करूंगा ।

कारण: मैंने एक बार एक ऐसी परियोजना में काम किया था जिसमें दो पुस्तकालयों का उपयोग किया गया था, जिसमें विभिन्न di रूपरेखाओं पर प्रत्यक्ष निर्भरता थी। उन दोनों के पास di-give-me-a-inst-of-XYZ जैसे चौखटे कोड थे। जहाँ तक मुझे पता है कि आप एक समय में केवल एक सक्रिय डाय-फ्रेमवर्क कार्यान्वयन कर सकते हैं।

इस तरह कोड के साथ आप लाभ से अधिक नुकसान कर सकते हैं।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.