निर्भरता इंजेक्शन: फील्ड इंजेक्शन बनाम कंस्ट्रक्टर इंजेक्शन?


61

मुझे पता है कि यह एक गर्म बहस है और समय के साथ राय बदल जाती है और सबसे अच्छा तरीका है।

: जब तक मैं विभिन्न ब्लॉग (exs पर पढ़ना शुरू किया मैं अपने वर्गों के लिए विशेष रूप से क्षेत्र इंजेक्शन का उपयोग करते थे petrikainulainen और schauderhaft और Fowler निर्माता इंजेक्शन के लाभों के बारे में)। मैंने अपनी निर्भरता को वैकल्पिक निर्भरता के लिए आवश्यक निर्भरता और सेटर इंजेक्शन के लिए निर्माता इंजेक्शन का उपयोग करने के लिए स्विच किया है।

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

आज की दुनिया में, क्या इंजेक्शन लगाने का एक पसंदीदा तरीका है? क्या फील्ड इंजेक्शन को प्राथमिकता दी जाती है?

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



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

2
@DavidArno: एक अपरिवर्तनीय वर्ग में, राज्य एक बार ... निर्माणकर्ता
राबर्ट हार्वे

1
@Davkd जो आप बता रहे हैं वह एनीमिक डोमेन मॉडल है। यह निश्चित रूप से प्रस्तावकों है, लेकिन यह वास्तव में किसी भी अधिक केंद्रित वस्तु नहीं है; जहां डेटा और उस डेटा पर कार्य करने वाले फंक्शंस एक साथ रहते हैं।
रिचर्ड टिंगल

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

जवाबों:


48

फ़ील्ड इंजेक्शन मेरे स्वाद के लिए "दूरी पर एक डरावना क्रिया" भी है।

अपने Google समूह पोस्ट में आपके द्वारा दिए गए उदाहरण पर विचार करें:

public class VeracodeServiceImplTest {


    @Tested(fullyInitialized=true)
    VeracodeServiceImpl veracodeService;
    @Tested(fullyInitialized=true, availableDuringSetup=true)
    VeracodeRepositoryImpl veracodeRepository;
    @Injectable private ResultsAPIWrapper resultsApiWrapper;
    @Injectable private AdminAPIWrapper adminApiWrapper;
    @Injectable private UploadAPIWrapper uploadApiWrapper;
    @Injectable private MitigationAPIWrapper mitigationApiWrapper;

    static { VeracodeRepositoryImpl.class.getName(); }
...
}

तो मूल रूप से आप जो कह रहे हैं, वह यह है कि "मेरे पास निजी राज्य के साथ यह वर्ग है, जिसमें मैंने @injectableएनोटेशन संलग्न किया है , जिसका अर्थ है कि राज्य को बाहर से कुछ एजेंट द्वारा स्वचालित रूप से आबादी दी जा सकती है, भले ही मेरा राज्य सभी निजी घोषित किया गया हो "

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

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

विकल्प पर विचार करें (यह C # होने जा रहा है, क्योंकि मैं इसे बेहतर जानता हूं, लेकिन जावा में संभवतः एक सटीक समकक्ष है):

public class VeracodeService
{        
    private readonly IResultsAPIWrapper _resultsApiWrapper;
    private readonly IAdminAPIWrapper _adminApiWrapper;
    private readonly IUploadAPIWrapper _uploadApiWrapper;
    private readonly IMitigationAPIWrapper _mitigationApiWrapper;

    // Constructor
    public VeracodeService(IResultsAPIWrapper resultsApiWrapper, IAdminAPIWrapper adminApiWrapper, IUploadAPIWrapper uploadApiWrapper,         IMitigationAPIWrapper mitigationApiWrapper)
    {
         _resultsAPIWrapper = resultsAPIWrapper;
         _adminAPIWrapper = adminAPIWrapper;
         _uploadAPIWrapper = uploadAPIWrapper;
         _mitigationAPIWrapper = mitigationAPIWrapper;
    }
}

पहले से ही मुझे इस वर्ग के बारे में कुछ बातें पता हैं। यह एक अपरिवर्तनीय वर्ग है; राज्य केवल निर्माणकर्ता (संदर्भ, इस विशेष मामले में) में निर्धारित किया जा सकता है। और क्योंकि सब कुछ एक इंटरफ़ेस से निकलता है, मैं कंस्ट्रक्टर में कार्यान्वयन को स्वैप कर सकता हूं, जो कि आपके मोक्स में आता है।

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

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


जब तक मैं आपके पोस्ट को गलत नहीं पढ़ता, आप वास्तव में उदाहरण को ठीक से नहीं देख रहे हैं। मेरा कार्यान्वयन VeracodeServiceआपके द्वारा लिखे गए (जावा बनाम C # में यद्यपि) के लगभग समान है। VeracodeServiceImplTestवास्तव में एक यूनिट टेस्ट वर्ग है। @Injectableखेतों अनिवार्य वस्तुओं संदर्भ में डाला जा रहा मज़ाक उड़ाया जाता है। @Testedक्षेत्र डि निर्माता परिभाषित के साथ वस्तु / वर्ग है। मैं आपके दृष्टिकोण से सहमत हूं जो क्षेत्र इंजेक्शन पर कंस्ट्रक्टर इंजेक्शन को प्राथमिकता देता है। हालाँकि, जैसा कि मैंने उल्लेख किया है, JMockit लेखक को इसके विपरीत लगता है और मैं यह समझने की कोशिश कर रहा हूं कि क्यों
एरिक बी।

यदि आप उस चर्चा के पहले पद को देखते हैं, तो आप देखेंगे कि मेरे रेपो वर्ग में लगभग एक ही अवज्ञा है।
एरिक बी।

यदि आप केवल परीक्षण कक्षाओं के बारे में बात कर रहे हैं, तो इससे कोई फर्क नहीं पड़ता। क्योंकि, परीक्षण कक्षाएं।
रॉबर्ट हार्वे

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

3
+1: हां, C # संस्करण में कोई जादू नहीं। यह एक मानक वर्ग है, इसमें निर्भरताएं हैं, सभी का उपयोग एक बिंदु पर किया जाता है, इससे पहले कि कक्षा का उपयोग किया जाए। क्लास का उपयोग DI कंटेनर के साथ किया जा सकता है, या नहीं। कक्षा में कुछ भी नहीं कहते हैं कि यह आईओसी या "स्वचालित निर्भरता इंजेक्शन" ढांचा है।
बाइनरी वॉरियर

27

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

क्या मैं चाहता हूं कि मेरी कक्षा केवल प्रतिबिंब के साथ तत्काल हो?

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

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

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

यह सब कई नए सवाल उठाता है:

  1. किसी अन्य प्लेटफ़ॉर्म पर कोड के भागों का उपयोग करने की संभावना क्या है?
  2. कितने यूनिट परीक्षण लिखे जाएंगे?
  3. प्रत्येक नई रिलीज़ को तैयार करने के लिए मुझे कितनी जल्दी चाहिए?
  4. ...

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

कई, क्षेत्र इंजेक्शन के खिलाफ कई तर्क।


3
+1 आप एक तंत्रिका मारा। मुझे किसी वर्ग को तात्कालिक बनाने के लिए प्रतिबिंब या DI / IoC ढांचे की आवश्यकता नहीं है। यह एम्स्टर्डम से पेरिस जाने के लिए रोम की ड्राइविंग की तरह है। माइंड यू आई लव डि। बस रूपरेखा के बारे में निश्चित नहीं है।
मार्जन वेनेमा

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

19

फील्ड इंजेक्शन से मुझे एक निश्चित "नहीं" वोट मिलता है।

रॉबर्ट हार्वे की तरह, यह मेरे स्वाद के लिए थोड़ा बहुत स्वचालित है। मैं निहित पर स्पष्ट कोड पसंद करता हूं, और जब यह स्पष्ट रूप से कोड के बारे में समझने और तर्क करने के लिए कठिन बनाता है, तो यह / के रूप में अप्रत्यक्ष रूप से सहन करता है।

Maciej Chałapuk की तरह, मुझे प्रतिबिंब या एक वर्ग को तुरंत बनाने के लिए DI / IoC ढांचे की आवश्यकता नहीं है। यह एम्स्टर्डम से पेरिस जाने के लिए रोम की ड्राइविंग की तरह है।

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

मुझे अपने टेस्ट बहुत सीधे-सादे लगते हैं। मैं एक IoC कंटेनरों या अन्य DI ढांचे की स्थापना के अप्रत्यक्षीकरण से गुजरना पसंद नहीं करता, फिर उन्हें परीक्षण के तहत मेरी कक्षा में स्थापित किया। यह सिर्फ अजीब लगता है।

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

कम से कम कंस्ट्रक्टर और सेटर इंजेक्शन के साथ, आपके पास अपने परीक्षणों में फ्रेमवर्क और / या प्रतिबिंब का उपयोग नहीं करने का विकल्प है।


यदि आप, उदाहरण के लिए, Mockito mockito.org का उपयोग करते हैं, तो आपको फ़ील्ड इंजेक्शन का उपयोग करते समय भी DI / IoC ढांचे की आवश्यकता नहीं है, और समानांतर और आगे में परीक्षण चला सकते हैं।
हंस-पीटर स्टॉर्र

1
@ ह्स्टोरो नाइस। हालांकि, इसका मतलब यह होना चाहिए कि मॉकिटो प्रतिबिंब का उपयोग कर रहा है (या जो भी जावा के बराबर कहा जाता है) ...
मार्जन वेनमा

5

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

तो, स्पष्ट होने के लिए:

फ़ील्ड इंजेक्शन:

@Autowired
private SomeService someService;

सेटर इंजेक्शन:

@Autowired
public void setSomeService(SomeService someService) {
    this.someService = someService;
}

लेकिन, मेरे लिए, वे समान चिंताओं को साझा करते हैं। और, मेरा पसंदीदा, निर्माता इंजेक्शन:

@AutoWired
public MyService(SomeService someService) {
    this.someService = someService;
}

मेरे पास यह मानने के कारण हैं कि कंस्ट्रक्टर इंजेक्शन सेटर / फील्ड इंजेक्शन से बेहतर है (मैं अपनी बात को प्रदर्शित करने के लिए कुछ स्प्रिंग लिंक उद्धृत करूंगा:

  1. परिपत्र निर्भरता को रोकें : वसंत सेम के बीच परिपत्र निर्भरता का पता लगाने में सक्षम है, जैसा @Tomasz ने समझाया। स्प्रिंग टीम को यह कहते हुए भी देखें ।
  2. वर्ग की निर्भरता स्पष्ट हैं : वर्ग की निर्भरता निर्माता में स्पष्ट हैं लेकिन hided क्षेत्र / सेटर इंजेक्शन के साथ। मैं अपनी कक्षाओं को फ़ील्ड / सेटर इंजेक्शन के साथ "ब्लैक बॉक्स" की तरह महसूस करता हूं। और वहाँ है (मेरे अनुभव से) डेवलपर्स के लिए एक प्रवृत्ति कई निर्भरता के साथ वर्ग के बारे में परेशान नहीं करती है, यह स्पष्ट है कि जब आप निर्माता इंजेक्शन (अगले आइटम देखें) का उपयोग करके वर्ग का मजाक उड़ाने की कोशिश करते हैं। एक समस्या जो डेवलपर्स को परेशान करती है सबसे अधिक हल होने की संभावना है। इसके अलावा, बहुत अधिक निर्भरता वाला एक वर्ग संभवतः एकल जिम्मेदारी सिद्धांत (एसआरपी) का उल्लंघन करता है।
  3. मॉक करने के लिए आसान और विश्वसनीय : फील्ड इंजेक्शन की तुलना में , यूनिट टेस्ट में मॉक करना आसान है, क्योंकि आपको क्लास के अंदर घोषित निजी बीन तक पहुंचने के लिए किसी भी संदर्भ मॉक या रिफ्लेक्शन टेक्निक की आवश्यकता नहीं है और आपको इसके द्वारा बेवकूफ नहीं बनाया जाएगा । आप बस क्लास को तत्काल करें और नकली बीन्स पास करें। समझने में आसान और आसान।
  4. कोड गुणवत्ता उपकरण आपकी मदद कर सकते हैं : सोनार जैसे उपकरण आपको बहुत जटिल होने वाली कक्षा के बारे में चेतावनी दे सकते हैं, क्योंकि बहुत सारे मापदंडों वाला एक वर्ग शायद बहुत जटिल वर्ग है और कुछ रिफ्लेक्टर की आवश्यकता है। जब फ़ील्ड फ़ील्ड / सेटर इंजेक्शन का उपयोग कर रहा हो तो यह उपकरण उसी समस्या की पहचान नहीं कर सकता है।
  5. बेहतर और स्वतंत्र कोड : @AutoWiredआपके कोड के बीच कम प्रसार के साथ, आपका कोड फ्रेमवर्क के कम निर्भर है। मुझे पता है कि एक परियोजना में डीआई फ्रेमवर्क को सरल करने की संभावना उचित नहीं है कि (जो ऐसा करता है, ठीक है?)। लेकिन यह दिखाता है, मेरे लिए, एक बेहतर कोड (मैंने इसे ईजेबी और लुकअप के साथ एक कठिन तरीके से सीखा है )। और वसंत के साथ आप @AutoWiredकंस्ट्रक्टर इंजेक्शन का उपयोग करके एनोटेशन को भी हटा सकते हैं ।
  6. अधिक एनोटेशन हमेशा सही जवाब नहीं है : के लिए कुछ कारणों से , मैं वास्तव में केवल व्याख्या का उपयोग करना, जब वे वास्तव में उपयोगी होते हैं की कोशिश करो।
  7. आप इंजेक्शन को अपरिवर्तनीय बना सकते हैं । अपरिवर्तनीयता एक बहुत ही स्वागत योग्य विशेषता है।

यदि आप अधिक जानकारी की तलाश कर रहे हैं, तो मैं स्प्रिंग ब्लॉग के इस पुराने (लेकिन अभी भी प्रासंगिक) लेख की सलाह देता हूं कि हमें बताया गया है कि वे इतने सेटर इंजेक्शन का उपयोग क्यों करते हैं और कंस्ट्रक्टर इंजेक्शन का उपयोग करने की सिफारिश करते हैं:

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

और यह नोट इस बारे में है कि वे क्यों मानते हैं कि कंस्ट्रक्टर एप्लिकेशन कोड के लिए अधिक उपयुक्त है:

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

अंतिम विचार

यदि आपका वास्तव में कंस्ट्रक्टर के लाभ के बारे में निश्चित नहीं है, तो शायद कंस्ट्रक्टर इंजेक्शन के साथ सेटर (फील्ड नहीं) को मिलाने का विचार एक विकल्प है, जैसा कि स्प्रिंग टीम द्वारा समझाया गया है :

चूंकि आप कंस्ट्रक्टर- और सेटर-आधारित DI दोनों को मिला सकते हैं, यह अनिवार्य निर्भरता के लिए कंस्ट्रक्टर तर्कों का उपयोग करने और वैकल्पिक निर्भरताओं के लिए बसने के लिए अंगूठे का एक अच्छा नियम है

लेकिन याद रखें कि फील्ड इंजेक्शन, शायद, तीन में से बचा जाना है


-5

क्या आपकी निर्भरता कक्षा के जीवनकाल के दौरान बदलने की संभावना है? यदि ऐसा है तो फ़ील्ड / प्रॉपर्टी इंजेक्शन का उपयोग करें। अन्यथा कंस्ट्रक्टर इंजेक्शन का उपयोग करें।


2
यह वास्तव में कुछ भी नहीं समझाता है। जब आप इसके बजाय उचित तरीके से कर सकते हैं तो निजी क्षेत्रों को क्यों इंजेक्ट करें?
रॉबर्ट हार्वे

यह निजी क्षेत्रों के बारे में कुछ भी कहां कहता है? मैं एक वर्ग के सार्वजनिक इंटरफ़ेस के बारे में बात कर रहा हूँ /
डैरेन यंग

प्रश्न में विधि इंजेक्शन बनाम कंस्ट्रक्टर इंजेक्शन के बारे में कोई तर्क नहीं है। जेमॉकिट के लेखक दोनों को बुरा मानते हैं। प्रश्न का शीर्षक देखें।
रॉबर्ट हार्वे

क्या सवाल यह नहीं कहता कि फील्ड इंजेक्शन बनाम कंस्ट्रक्टर इंजेक्शन?
डैरेन यंग

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