निर्भरता इंजेक्शन के विपरीत निरूपित करने के लिए तकनीकी शब्द?

Question

यह विशुद्ध रूप से तकनीकी प्रश्न के बजाय नामकरण (तकनीकी लेखन) का अधिक है। मैं हमारे आवेदन में निर्भरता इंजेक्शन के विस्तार के आसपास केंद्रित एक refactoring प्रस्ताव लिखने के लिए (और इसे अपने आप को सौंपा) की कोशिश कर रहा हूँ। जबकि हम ऑटोबायरिंग बीन्स के लिए स्प्रिंग का उपयोग करते हैं , अभी भी ऐसे उदाहरण हैं जो तत्काल बीन्स का उपयोग करते हैं MyClass obj = new MyClass(...), जो पूरी तरह से इंजेक्ट किया जा सकता है। मैं अपने प्रस्ताव को सुरुचिपूर्ण नामकरण का उपयोग करना चाहूंगा और उचित अवधि के साथ DI के डिजाइन पैटर्न का उल्लेख कर सकता हूं।

क्या "टाइट कपलिंग" एक पर्याप्त शब्द है जो डिटोनियम के रूप में है?

Comments

हां, युग्मन स्पष्ट रूप से अन्य वर्गों में कोड नाम और कोड आधार के परिणामस्वरूप राज्य का उपयोग करने के दोनों कार्यों का वर्णन करता है।

— किलियन फोथ

नहीं, तंग युग्मन केवल परिणामी कोड की संपत्ति का वर्णन करता है, डीआई के विपरीत नहीं। आप DI का उपयोग कर सकते हैं और अभी भी पूरी तरह से अलग कारणों के लिए तंग युग्मन है।

— डॉक्टर ब्राउन

सहमत हैं कि DI और तंग युग्मन विपरीत नहीं हैं ।

— एरिक किंग

@EricKing दिखावा। रास्ते से +1।

— कैंडिड_ऑरेंज सेप

"निर्भरता सक्शन" ।

— सेलेडमनीडे

Answer 1

नहीं। निर्भरता इंजेक्शन के साथ तुलना में तंग युग्मन बहुत अधिक है।

निर्भरता इंजेक्शन कार्यान्वयन के निर्णय को बाहरी बनाता है। यह सड़ने के लिए एक लंबा रास्ता तय करता है लेकिन युग्मन सिर्फ इस से अधिक है।

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

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

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

Comments

हां, हार्ड कोडिंग (एक निर्भरता), जैसा कि इसे (रनटाइम पर) इंजेक्ट करने के विपरीत, ठीक वैसा ही है जैसा मैं सुझाव देने जा रहा था, आप भी मुझसे थोड़े तेज थे।

— डॉक ब्राउन

@DocBrown मैं कभी-कभी चाहता हूं कि इस जगह ने तेजी से होने पर इतना जोर नहीं दिया। मैं सुनना चाहता हूँ कि आप इसे कैसे डालेंगे।

— कैंडिड_ऑरेंज सेप

अच्छा जवाब - निर्भरता इंजेक्शन decoupling का मतलब नहीं है। विश्वास करना अन्यथा एक खराब सड़क की ओर जाता है

— Ant P

@CandiedOrange शायद किसी को मेटा में सुझाव देना चाहिए कि उत्तर समय की अवधि के लिए छिपे रहें। और / या वोटों को सार्वजनिक दृश्य से Nघंटों तक छिपाया जा सकता है ... या जब तक कोई जवाब नहीं चुना जाता है। मुझे पता है कि मैं पूरी तरह से वस्तुनिष्ठ नहीं हूँ जब एक उत्तर में पहले से ही 10 वोट हैं और अन्य 5 उत्तरों में कोई नहीं है!

— svidgen

@svidgen ने मेटा पर "पश्चिम में सबसे तेज़ बंदूक" की खोज की। इस मुद्दे का पहले से ही एक लंबा इतिहास रहा है।

— कैंडिड_ऑरेंज सेप

Answer 2

सख्ती से बोलना, निर्भरता इंजेक्शन केवल वास्तव में नहीं निर्भरता इंजेक्शन का विरोध करता है - और इसलिए किसी भी निर्भरता प्रबंधन रणनीति जो निर्भरता इंजेक्शन नहीं है ।

[अनवांटेड] युग्मन, हालांकि वास्तव में एक ऑर्थोगोनल मुद्दा नहीं है, या तो हो सकता है या किसी भी तरह से कम हो सकता है। ये दोनों युग्मित हैं DependencyClass:

public DependencyInjectedConstructor(DependencyClass dep) {
  dep.do();
}

public DependencyLookupConstructor() {
  var dep = new DependencyClass();
  dep.do();
}

DependencyLookupConstructorDependencyClassइस मामले में एक विशेष के लिए युग्मित है । लेकिन, वे दोनों के लिए युग्मित हैं DependencyClass। असली बुराई, अगर यहां एक है, तो जरूरी नहीं कि कपलिंग हो, तो इसे DependencyLookupConstructorबदलने की जरूरत है अगर DependencyClassअचानक अपने स्वयं के आश्रितों को इंजेक्शन की आवश्यकता होती है ¹ ।

हालाँकि, यह निर्माता / वर्ग और भी अधिक कपल है:

public DependencyLocatingConstructor() {
  var dep = ServiceLocator.GetMyDoer();
  dep.do();
}

आप सी # में काम कर रहे हैं, ऊपर अपनी अनुमति देगा ServiceLocatorवापस जाने के लिए कुछ भी जब GetMyDoer()शुरू हो जाती है, यह है, जब तक कि यह कर सकते हैं do()क्या DependencyLocatingConstructorयह है do()। कम्पाइल-टाइम हस्ताक्षर सत्यापन का लाभ आपको पूर्ण इंटरफ़ेस ^{2 के साथ} जोड़े बिना भी मिलता है ।

तो, अपना जहर उठाओ।

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

• सेवा लोकेटर पैटर्न
• निर्भरता लोकेटर / स्थान
• प्रत्यक्ष वस्तु / निर्भरता निर्माण
• छिपी हुई निर्भरता
• "निर्भरता इंजेक्शन नहीं"

---

^{1. विडंबना यह है कि उच्च स्तर पर DI हल करने वाली समस्याओं में से कुछ निम्न स्तर पर DI का उपयोग करते हुए [ओवर-] के परिणाम की तरह हैं। मुझे उन सभी जगहों पर मुट्ठी भर स्थानों को समायोजित करने के परिणामस्वरूप अनावश्यक जटिलता के साथ कोडबेस पर काम करने का आनंद मिला है, जहां उस जटिलता ने वास्तव में मदद की है ... मैं बुरी तरह से जोखिम में हूँ।}

^{2. सेवा स्थान का उपयोग करने से भी आपको आसानी से एक ही प्रकार की विभिन्न निर्भरता को इनवॉइसिंग कोड से उनकी कार्यात्मक भूमिका द्वारा निर्दिष्ट करने की अनुमति मिलती है , जबकि अभी भी काफी हद तक अज्ञेय है कि कैसे निर्भरता का निर्माण किया जाता है। आपको इसका समाधान करना मान लीजिए Userया IUser, उदाहरण के लिए: विभिन्न प्रयोजनों के लिए Locator.GetAdministrator()बनाम Locator.GetAuthor()या जो कुछ भी -। मेरा कोड यह पूछ सकता है कि कार्यात्मक रूप से इसकी आवश्यकता के बिना भी यह जानना चाहिए कि यह किस इंटरफेस का समर्थन करता है।}

Comments

इसके लिए मुक्ति DependencyInjectedConstructor(DependencyClass dep)यह है कि DependencyClass एक इंटरफ़ेस या अमूर्त वर्ग हो सकता है। यही कारण है कि यह मुझे दुखी करता है कि सी # कोडर्स एक इंटरफ़ेस उपसर्ग का उपयोग करते हैं, जैसे कि IDependency। ग्राहक के रूप में, यह वास्तव में मेरा व्यवसाय नहीं है कि यह निर्भरता क्या है। जब तक मैं इसका निर्माण नहीं करता, तब तक मुझे यह जानना होगा कि इससे कैसे बात की जाए। क्या यह किसी और की समस्या है।

— कैंडिड_ऑरेंज सेप

अंक होने के नाते, DI अभी भी आपको उस इंटरफ़ेस से जोड़े हैं, और इसके लिए यह आवश्यक नहीं है कि DependencyClassवह एक सार इंटरफ़ेस हो। इसके लिए केवल यह आवश्यक है कि निर्माण / विन्यास / स्थान तर्क मौजूदा "कहीं और हो।" ... खैर, और सवाल का अधिक प्रासंगिक, बिंदु यह है कि DI "तंग युग्मन के विपरीत" नहीं है :)

— svidgen

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

— svidgen

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

— कैंडिड_ऑरेंज सेप

मुझे यकीन नहीं है कि हम कुल असहमति में हैं। लेकिन, स्पष्ट करने के लिए ... वस्तुओं को आंतरिक रूप से अपने स्वयं के इंटरफेस के लिए युग्मित किया जाता है, हाँ। लेकिन, यदि इंटरफ़ेस स्पष्ट रूप से नामित है, तो इंटरफ़ेस केवल निर्भरता-युग्मन लागू करता है। C # में, लोकेटर से एक ऑब्जेक्ट का उपयोग करना dynamicया varप्राप्त करना आइए आप इंटरफ़ेस को अनदेखा करते हैं और किसी भी वर्ग का उपयोग करते हैं do()जो आपको आवश्यक है, चाहे वह वर्ग कुछ IDoerइंटरफ़ेस को लागू करता हो। दूसरे शब्दों में, अगर हमारे पास A-> B <-C है, तो DI C से A को डिकॉय करता है, लेकिन इसके लिए A और C दोनों को B से युग्मित करने की आवश्यकता होती है, और D का उपयोग करने से रोकता है, भले ही D होगा do()।

— svidgen

Answer 3

मुझे पता नहीं है कि विशिष्ट, व्यापक रूप से स्वीकृत उद्योग शब्दावली है, लेकिन जो विकल्प दिमाग में आते हैं उनमें आंतरिक उदाहरण निर्माण , आंतरिक निर्भरता निर्माण , स्थानीय निर्भरता या स्थानीय रूप से स्कोप्ड निर्भरता शामिल हैं ।

Comments

मुझे पसंद है instance creationलेकिन यह पर्याप्त विशिष्ट नहीं है। DI उदाहरण बनाता है, लेकिन नियंत्रक के माध्यम से और आवेदन के स्तर पर नहीं। हो सकता हैinternal instance creation

— उभयचर

Answer 4

मैं निर्भरता एनकैप्सुलेशन के साथ जाऊंगा । यह व्यक्त करता है कि निर्भरता फिर से आने और जाने के बजाय बंद है।