निर्भरता इंजेक्शन का उपयोग करते समय कभी भी 'नया' के लिए कोई मामला है?

Question

क्या निर्भरता इंजेक्शन का मतलब है कि आपको कभी भी 'नया' कीवर्ड की आवश्यकता नहीं है? या क्या संग्रहों जैसे साधारण पत्ते वर्गों को सीधे बनाना उचित है?

मैं नीचे दिए गए उदाहरण में तुलनित्र, क्वेरी और दाव इंजेक्षन, लेकिन SortedSet सीधे instantiated है:

public Iterable<Employee> getRecentHires() 
{ 
    SortedSet<Employee> entries = new TreeSet<Employee>(comparator); 
    entries.addAll(employeeDao.findAll(query)); 
    return entries; 
} 

Answer 1

सिर्फ इसलिए कि निर्भरता इंजेक्शन एक उपयोगी पैटर्न मतलब यह नहीं है कि हम सब कुछ के लिए इसका इस्तेमाल करते हैं है। यहां तक ​​कि DI का उपयोग करते समय, अक्सर नया की आवश्यकता होगी। अभी तक नया मत हटाएं।

Answer 2

हां, ज़ाहिर है।

निर्भरता इंजेक्शन उन परिस्थितियों के लिए है जहां कई संभावित तत्काल लक्ष्य हो सकते हैं जिनके ग्राहक संकलित समय के बारे में जागरूक नहीं हो सकते (या विकल्प बनाने में सक्षम) हो सकते हैं।

हालांकि, पर्याप्त परिस्थितियां हैं जहां आप जानते हैं कि आप तुरंत क्या करना चाहते हैं, इसलिए DI की कोई आवश्यकता नहीं है।

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

Answer 3

नया का उपयोग करने में कुछ भी गलत नहीं है जैसे यह आपके कोड स्निपेट में दिखाया गया है।

स्ट्रिंग स्निपेट को जोड़ने के इच्छुक मामले पर विचार करें। आप स्ट्रिंगबिल्डर के लिए इंजेक्टर से क्यों पूछना चाहेंगे?

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

Answer 4

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

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

एक अंतिम नोट: जब किसी भी कारण से किसी क्षेत्र को इंजेक्शन नहीं दिया जा सकता है, लेकिन मैं अभी भी एक परीक्षण में इसे मजाक करना चाहता हूं, मुझे Junit-addons PrivateAccessor कक्षा मिली है जो वर्ग के निजी क्षेत्र को नकली में बदलने में सक्षम है ऑब्जेक्ट EasyMock (या जेएमॉक या जो भी अन्य मॉकिंग फ्रेमवर्क आप पसंद करते हैं) द्वारा बनाया गया है।

Answer 5

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

तो जब DI अधिक है तो मैं 'नया' उपयोग करता हूं और इसे रोल करने देता हूं।

पूर्व: मेरे लिए नियंत्रक परत पर देखने के लिए एक मॉडल तार तार .. यह हमेशा DI के माध्यम से किया जाता है। मेरे ऐप्स का उपयोग करने वाले किसी भी एल्गोरिदम, DI और किसी भी प्लग करने योग्य प्रतिबिंबित कोड, DI। डाटाबेस परत .. DI लेकिन मेरे सिस्टम में इस्तेमाल होने वाली किसी भी अन्य वस्तु को एक सामान्य 'नया' के साथ संभाला जाता है।

उम्मीद है कि इससे मदद मिलती है।

Answer 6

यह सच है कि आज, ढांचे से प्रेरित वातावरण आप वस्तुओं को कम और कम करते हैं। उदाहरण के लिए, सर्लेट्स को सर्वलेट कंटेनर द्वारा तुरंत चालू किया जाता है, स्प्रिंग आदि के साथ वसंत में बीन्स

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