चार के गैंग में निर्भरता इंजेक्शन पैटर्न को क्यों नहीं शामिल किया गया?

Question

चार के गिरोह में निर्भरता इंजेक्शन पैटर्न को क्यों नहीं अपनाया गया ? क्या GOF की पूर्व-तिथि व्यापक स्वचालित परीक्षण थी? क्या निर्भरता इंजेक्शन अब एक कोर पैटर्न माना जाता है?

Comments

.. क्योंकि "निर्भरता इंजेक्शन" एक पैटर्न नहीं है!

— दीपन मेहता

@DipanMehta stackoverflow.com/questions/823387/…

— टॉम

जो कुछ भी दोहराया जाता है वह दोहराव का एक पैटर्न बनाता है। सभी डिज़ाइन तत्व (जो अद्वितीय, पागल विचार नहीं हैं) "पैटर्न" हैं।

— S.Lott

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

— नज़र मज्जा

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

— जेम्स

Answer 1

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

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

जावा ने मल्टीपल-एंट्री-पॉइंट प्रोग्रामिंग को अधिक स्पष्ट बनाया। मूल डॉट-कॉम बूम के समय तक, यूनिट-परीक्षण एक प्रसिद्ध तकनीक थी, लेकिन यह वास्तव में JUnit (लगभग 2001?) था जिसके कारण यह आग लग गई और एक सार्वभौमिक अभ्यास बन गया।

हालाँकि रणनीति और एक इंटरफ़ेस के लिए प्रोग्रामिंग की सामान्य अवधारणा GOF और 90 के दशक के मध्य के ज़ेगेटिस्ट का हिस्सा थी, इंजेक्शन का विचार पार्टी के लिए काफी देर से आया (लगभग '03 -'05?)। ईमानदारी से, मेरे भूरे बाल अभी भी DI के उस पहलू के बारे में काफी संदिग्ध हैं ("मेरे लॉन से दूर हो जाओ, तुम कॉर्नर कॉन्फ़िगरेशन फ़ाइलें!")।

Comments

मुझे पछतावा है कि मेरे पास केवल इतना वोट है, लेकिन इस तरह के एक सुखद जवाब के लिए मुझे वोट देना पड़ा।

@ लॉरी ओरेन: कन्वेंशन आधारित पंजीकरण के लिए स्कैनिंग बहुत हद तक कॉन्फ़िगरेशन कोड को सरल करता है और आईओसी कंटेनरों में एक्सएमएल कॉन्फ़िगरेशन को व्यावहारिक रूप से समाप्त करता है।

— क्वेंटिन-स्टारिन

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

— marco-fiset

Answer 2

उन्होंने इसे रणनीति कहा ।

उनकी रणनीति में जटिल-ध्वनि नाम के बिना निर्भरता इंजेक्शन की सभी विशेषताएं हैं।

Comments

-1। माफ़ कीजिये! रणनीति पैटर्न का डिपेंडेंसी इंजेक्शन से कोई लेना-देना नहीं है।

— दीपन मेहता

वे भयानक रूप से करीब हैं। देखें: क्या रणनीति पैटर्न के लिए निर्भरता इंजेक्शन सिर्फ एक और नाम है? और रणनीति पैटर्न और निर्भरता इंजेक्शन के बीच अंतर क्या है?

— छिपकली

@ दिपन: इससे नीचे जाने से पहले, आप बेहतर उत्तर के बारे में पाँच मिनट सोचते हैं।

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

यह सच है कि डिपेंडेंसी इंजेक्शन को रणनीति पैटर्न के समान माना जा सकता है, लेकिन जब लोग कहते हैं कि निर्भरता इंजेक्शन का मतलब है कि वे आमतौर पर नियंत्रण के व्युत्क्रम का मतलब है, जो मुझे लगता है कि रणनीति (esp। IoC कंटेनर) से बहुत अधिक अलग है।

— मैटवेवी

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

— फाल्कन

Answer 3

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

रणनीति चर्चा में आ सकती है लेकिन रणनीति निर्भरता इंजेक्शन के बारे में बात नहीं करती है। लेकिन जब किसी एकल परियोजना या dll (सभी वर्ग और इंटरफेस एक ही परियोजना में रहते हैं) में रणनीति पैटर्न का उपयोग करते हुए यह प्रतीत होता है कि हम निर्भरता इंजेक्शन कर रहे हैं। वास्तव में हम नहीं हैं।

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

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

Comments

इस सवाल का जवाब नहीं है। कृपया अन्य प्रश्नों के उत्तर देने के बजाय मूल प्रश्न पढ़ें :)

— एंड्रेस एफ।

Answer 4

उत्तर रणनीति 100% सही है। मैंने इसे वोट दिया लेकिन टिप्पणी कर सकता हूं।

"रणनीति एल्गोरिदम का उपयोग करने वाले ग्राहकों से स्वतंत्र रूप से भिन्न होती है। [1] रणनीति गामा एट अल द्वारा प्रभावशाली पुस्तक डिजाइन पैटर्न में शामिल पैटर्न में से एक है। जिसने सॉफ्टवेयर डिजाइन का वर्णन करने के लिए पैटर्न का उपयोग करने की अवधारणा को लोकप्रिय बनाया।"

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

रिपॉजिटरी पैटर्न एक नया पैटर्न नहीं है, यह टेम्पलेट पैटर्न है।

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

अक्सर पैटर्न संयुक्त और नामित कई पैटर्न होते हैं जैसे कि MVC पैटर्न।

GOF में इस्तेमाल किए गए प्योर एब्सट्रैक्ट क्लासेस का इंटरफेस नहीं था, और एक से अधिक क्लास से वार करने की C ++ की क्षमता का भी फायदा उठाया।

Comments

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

— जूल्स