कंस्ट्रक्टर या प्रॉपर्टी सेटरों के माध्यम से निर्भरता इंजेक्शन

151

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

यह यहाँ मौजूदा कोड के साथ पैटर्न प्रतीत नहीं होता है, इसलिए मैं यह पता लगाने के लिए देख रहा हूँ कि सामान्य सहमति क्या है, पेशेवरों और बिल्डरों बनाम संपत्तियों की विपक्ष। क्या संपत्ति बसने वालों का उपयोग बेहतर है?

dependency-injection inversion-of-control

— नाल कनॉटघटन
स्रोत

126

अच्छा वह निर्भर करता है :-)।

यदि वर्ग निर्भरता के बिना अपना काम नहीं कर सकता है, तो उसे कंस्ट्रक्टर में जोड़ें। वर्ग को नई निर्भरता की आवश्यकता है, इसलिए आप चाहते हैं कि आपका परिवर्तन चीजों को तोड़ दे। इसके अलावा, एक ऐसा वर्ग बनाना जो पूरी तरह से आरंभिक नहीं है ("दो-चरणीय निर्माण") एक एंटी-पैटर्न (IMHO) है।

यदि वर्ग निर्भरता के बिना काम कर सकता है, तो एक सेटर ठीक है।

— sleske
स्रोत

11

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

— मार्क लिंडेल

3

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

— 30:10

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

— पैट्रिक सज्जापस्की

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

— 0

1

इस पर एक अच्छा राइटअप एक्स्प्लवेज़अवाज ।different

— types-

21

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

इसके अलावा, पुराने कंस्ट्रक्टर के हर उपयोग को बदलने से खुद को रोकने के लिए, बस पुराने और नए कंस्ट्रक्टर के बीच एक अस्थायी पुल के रूप में कंस्ट्रक्शन चाइनिंग लागू करें।

public class ClassExample
{
    public ClassExample(IDependencyOne dependencyOne, IDependencyTwo dependencyTwo)
        : this (dependnecyOne, dependencyTwo, new DependnecyThreeConcreteImpl())
    { }

    public ClassExample(IDependencyOne dependencyOne, IDependencyTwo dependencyTwo, IDependencyThree dependencyThree)
    {
        // Set the properties here.
    }
}

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

— डॉक्टर नीला
स्रोत

यदि नया पैरामीटर के लिए एक उचित डिफ़ॉल्ट मान है, तो बेशक कंस्ट्रक्टर केवल काम करता है। लेकिन अन्यथा आप किसी भी तरह से चीजों को तोड़ने से बच नहीं सकते ...

— sleske

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

— डॉक्टर ब्लू

1

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

— नियाल कनॉटघटन

17

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

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

— जो
स्रोत

इसके लिए एक प्लस। इसके अलावा यह बहुत

— हद तक

11

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

— epitka
स्रोत

11

सामान्य पसंदीदा दृष्टिकोण जितना संभव हो उतना रचनात्मक इंजेक्शन का उपयोग करना है।

कन्स्ट्रक्टर इंजेक्शन वास्तव में बताता है कि ऑब्जेक्ट को ठीक से काम करने के लिए क्या आवश्यक निर्भरताएं हैं - एक वस्तु को नया करने और उस पर एक विधि को कॉल करते समय दुर्घटनाग्रस्त होने से ज्यादा कुछ भी कष्टप्रद नहीं है क्योंकि कुछ निर्भरता निर्धारित नहीं है। एक निर्माता द्वारा लौटाई गई वस्तु एक कार्यशील स्थिति में होनी चाहिए।

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

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

(पूर्व उत्तर नीचे)

मुझे लगता है कि यदि इंजेक्शन अनिवार्य है तो कंस्ट्रक्टर इंजेक्शन बेहतर है। यदि यह बहुत सारे कंस्ट्रक्टर को जोड़ता है, तो कंस्ट्रक्टरों के बजाय कारखानों का उपयोग करने पर विचार करें।

यदि इंजेक्शन वैकल्पिक है, या यदि आप इसे आधे रास्ते में बदलना चाहते हैं, तो सेटर इंजेक्शन अच्छा है। मैं आम तौर पर वासियों को पसंद नहीं करता, लेकिन यह स्वाद की बात है।

— फिलिप
स्रोत

मेरा तर्क है कि आमतौर पर इंजेक्शन के माध्यम से आधे रास्ते को बदलना खराब शैली है (क्योंकि आप अपनी वस्तु में छिपा हुआ राज्य जोड़ रहे हैं)। लेकिन कोई नियम w / o अपवाद नहीं ...

— sleske

हां, इसीलिए मैंने कहा कि मुझे सेटर बहुत पसंद नहीं आया ... मुझे कंस्ट्रक्टर का तरीका पसंद है क्योंकि इसे बदला नहीं जा सकता।

— फिलिप

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

— मीटिटस

@ मर्को कि मेरा पूर्व उत्तर है और आप सही हैं। यदि कई निर्माता हैं, तो मैं तर्क दूंगा कि वर्ग बहुत सारी चीजें करता है :-) या एक अमूर्त कारखाने पर विचार करें।

— फिलिप

7

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

जब तक वर्गों इंटरफ़ेस (एपीआई) स्पष्ट है कि इसे अपने कार्य को करने की आवश्यकता है, तो आप अच्छे हैं।

— nkr1pt
स्रोत

कृपया बताएं कि आप नीच क्यों हैं?

— nkr1pt

3

हां, बहुत सारे तर्कों वाले कंस्ट्रक्टर खराब हैं। यही कारण है कि आप बहुत सारे निर्माता मापदंडों के साथ रिफ्लेक्टर कक्षाएं :-)।

— साल्के

10

@ nkr1pt: ज्यादातर लोग (मुझे शामिल किया गया) सहमत हैं कि अगर यह इंजेक्शन नहीं किया जाता है तो यह एक ऐसे वर्ग का निर्माण करने की अनुमति देता है जो आपको एक वर्ग बनाने में विफल कर देता है। मेरा मानना है कि किसी ने इसलिए व्यक्तिगत बयान के अपने बयान पर आपत्ति जताई।

— दोपहर

7

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

— रस कैम
स्रोत

1

मुझे लगता है कि पैटर्न का आधिकारिक नाम "टेम्पलेट विधि" है।

— डेविडजल्सन

6

मैं कंस्ट्रक्टर इंजेक्शन पसंद करता हूं क्योंकि यह एक वर्ग की निर्भरता आवश्यकताओं को "लागू" करने में मदद करता है। यदि यह कोटर में नहीं है, तो एक उपभोक्ता को ऐप को संकलित करने के लिए ऑब्जेक्ट सेट करना होगा। यदि आप सेटर इंजेक्शन का उपयोग करते हैं, तो उन्हें पता नहीं हो सकता है कि उन्हें रन टाइम तक कोई समस्या है - और ऑब्जेक्ट के आधार पर, रन टाइम में देर हो सकती है।

मैं अभी भी समय-समय पर सेटर इंजेक्शन का उपयोग करता हूं जब इंजेक्शन वाली वस्तु को आरंभीकरण की तरह स्वयं काम करने की आवश्यकता होती है।

— ctacke
स्रोत

6

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

मैं उन चीजों को सेट करने के लिए प्रॉपर्टी इंजेक्शन का भी उपयोग करता हूं, जिनमें कंटेनर का उपयोग नहीं होता है जैसे कि कंटेनर का उपयोग करके बनाए गए प्रस्तुतकर्ता पर ASP.NET View।

मुझे नहीं लगता कि यह इनकैप्सुलेशन को तोड़ता है। आंतरिक कामकाज आंतरिक रहना चाहिए और निर्भरताएं एक अलग चिंता से निपटती हैं।

— डेविड किफ़
स्रोत

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

— निल कनॉटघटन

बस एक अच्छा लंबा जवाब लिखा है और इस साइट पर एक अपवाद के कारण इसे खो दिया है !! :( संक्षेप में, बेसकेल्स का उपयोग आमतौर पर तर्क को फिर से उपयोग करने के लिए किया जाता है। यह तर्क बहुत आसानी से उपवर्ग में जा सकता है ... इसलिए आप बेसकलैस और उपवर्ग = एक चिंता के बारे में सोच सकते हैं, जो कई बाहरी वस्तुओं पर निर्भर है, अलग-अलग काम करो। आपके पास जो निर्भरता है, इसका मतलब यह नहीं है कि आपको कुछ भी उजागर करने की आवश्यकता है जो आपने पहले निजी रखी होगी।

— डेविड किफ़

3

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

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

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

— steve314
स्रोत

3

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

वैकल्पिक मापदंडों का उपयोग केवल फ्रेमवर्क में पूरा किया जा सकता है जो उनका समर्थन करते हैं, जैसे कि .NET 4 (C # और VB.NET दोनों के लिए, हालांकि VB.NET हमेशा उनके पास है)। बेशक, आप अपनी कक्षा के उपभोक्ता द्वारा पुन: असाइन की जा सकने वाली संपत्ति का उपयोग करके समान कार्यक्षमता को पूरा कर सकते हैं, लेकिन आपको निजी इंटरफ़ेस ऑब्जेक्ट को कंस्ट्रक्टर के एक पैरामीटर को सौंपा जाने से अपरिवर्तनीयता का लाभ नहीं मिलता है।

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

— बेन मैककॉर्मैक
स्रोत

1

यह एक पुरानी पोस्ट है, लेकिन अगर भविष्य में इसकी आवश्यकता हो तो शायद यह किसी काम का हो:

https://github.com/omegamit6zeichen/prinject

मेरे पास एक समान विचार था और इस ढांचे के साथ आया था। यह शायद पूरी तरह से दूर है, लेकिन यह संपत्ति के इंजेक्शन पर ध्यान देने वाली एक रूपरेखा का विचार है

— मार्कस
स्रोत

0

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

— रामाराव गंगीना
स्रोत

1

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

— फ्रेड

0

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

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

— डेविड स्पेनार्ड
स्रोत