कंटेनर के साथ निर्भरता इंजेक्शन का उपयोग करने और सेवा लोकेटर का उपयोग करने के बीच क्या अंतर है?


107

मैं समझता हूं कि एक वर्ग के अंदर सीधे निर्भरता को बुरा व्यवहार माना जाता है। यह समझ में आता है कि बहुत कसकर जोड़ों को सब कुछ करने के लिए जो बदले में परीक्षण बहुत कठिन बनाता है।

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

दोनों में क्या अंतर है? मैं एक को दूसरे पर क्यों चुनूंगा?


3
यह StackOverflow पर पूछा गया (और उत्तर दिया गया है): stackoverflow.com/questions/8900710/…
Kyralessa

2
मेरी राय में यह डेवलपर्स के लिए असामान्य नहीं है कि वे दूसरों को यह सोचकर धोखा दें कि उनकी सेवा लोकेटर निर्भरता इंजेक्शन है। वे ऐसा इसलिए करते हैं क्योंकि निर्भरता इंजेक्शन अक्सर अधिक उन्नत माना जाता है।
घुमान


1
मुझे आश्चर्य है कि किसी ने भी उल्लेख नहीं किया है कि सेवा लोकेटरों के साथ यह जानना कठिन है कि एक क्षणिक संसाधन को कैसे नष्ट किया जा सकता है। मैंने हमेशा सोचा कि यह प्राथमिक कारण था।
बुआ बुह

जवाबों:


126

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

एक कंटेनर जो कंस्ट्रक्टर तर्कों के माध्यम से निर्भरता की आपूर्ति करता है, सबसे स्पष्टता देता है। हम सही सामने देखते हैं कि एक वस्तु को AccountRepositoryए, और ए दोनों की आवश्यकता है PasswordStrengthEvaluator। सेवा लोकेटर का उपयोग करते समय, वह जानकारी तुरंत कम स्पष्ट होती है। आप एक मामले को तुरंत देख लेंगे, जहां एक वस्तु, ओह, 17 निर्भरताएं हैं, और अपने आप से कहें, "हम्म, यह बहुत पसंद है। वहां क्या चल रहा है?" एक सेवा लोकेटर को कॉल विभिन्न तरीकों के चारों ओर फैलाया जा सकता है, और सशर्त तर्क के पीछे छिपा हो सकता है, और आपको एहसास नहीं हो सकता है कि आपने "भगवान वर्ग" बनाया है - एक जो सब कुछ करता है। हो सकता है कि वह वर्ग 3 छोटी कक्षाओं में परिलक्षित किया जा सकता है जो अधिक केंद्रित हैं, और इसलिए अधिक परीक्षण योग्य हैं।

अब परीक्षण पर विचार करें। यदि कोई ऑब्जेक्ट अपनी निर्भरता प्राप्त करने के लिए किसी सेवा लोकेटर का उपयोग करता है, तो आपके परीक्षण ढांचे को भी सेवा लोकेटर की आवश्यकता होगी। एक परीक्षण में, आप परीक्षण के अंतर्गत वस्तु के लिए उनकी निर्भरता की आपूर्ति करने सेवा लोकेटर कॉन्फ़िगर कर देंगे - हो सकता है एक FakeAccountRepositoryऔर एक VeryForgivingPasswordStrengthEvaluatorहै, और फिर परीक्षण चलाने। लेकिन यह ऑब्जेक्ट के कंस्ट्रक्टर में निर्भरता को निर्दिष्ट करने से अधिक काम है। और आपका परीक्षण ढांचा भी सेवा लोकेटर पर निर्भर हो जाता है। यह एक और चीज है जिसे आपको हर परीक्षण में कॉन्फ़िगर करना होगा, जिससे लेखन परीक्षण कम आकर्षक हो जाता है।

इसके बारे में मार्क सेमैन के लेख के लिए "Serivce Locator एक एंटी-पैटर्न है" देखें। यदि आप .Net दुनिया में हैं, तो उसकी पुस्तक प्राप्त करें। यह बहुत अच्छा है।


1
गैरी मैकलीन हॉल द्वारा C # के माध्यम से मैंने एडाप्टिव कोड के बारे में जो प्रश्न सोचा था, उसे पढ़ना , जो इस उत्तर के साथ बहुत अच्छी तरह से संरेखित करता है। इसमें कुछ अच्छे उपमाएँ हैं जैसे सेवा लोकेटर एक सुरक्षित की कुंजी है; जब एक वर्ग को सौंप दिया जाता है, तो यह उस समय पर निर्भरता पैदा कर सकता है जो शायद आसान न हो।
डेनिस

10
IMO को एक चीज constructor supplied dependenciesबनाम service locatorमें शामिल करने की जरूरत है कि पूर्व को संकलित किया जा सकता है , जबकि बाद वाला केवल सत्यापित रनटाइम हो सकता है।
andras

2
इसके अलावा, एक सेवा लोकेटर एक घटक को कई निर्भरता होने से हतोत्साहित नहीं करता है। अगर आपको अपने कंस्ट्रक्टर में 10 पैरामीटर जोड़ने हैं तो आपके पास बहुत अच्छा अर्थ है कि आपके कोड में कुछ गड़बड़ है। हालाँकि, यदि आप किसी सेवा लोकेटर को 10 स्थिर कॉल करने के लिए होते हैं, तो यह आसानी से स्पष्ट नहीं हो सकता है कि आपको किसी प्रकार का मुद्दा मिल गया है। मैंने एक बड़े प्रोजेक्ट पर सर्विस लोकेटर के साथ काम किया है और यह सबसे बड़ा मुद्दा था। सिट बैक, रिफ्लेक्ट, रिडिजाइन और रिफ्लेक्टर की बजाए शॉर्ट सर्किट एक नया रास्ता बनाना बहुत आसान था।
पेस

1
परीक्षण के बारे में - But that's more work than specifying dependencies in the object's constructor.मुझे आपत्ति है। सेवा लोकेटर के साथ आपको केवल 3 निर्भरताएँ निर्दिष्ट करने की आवश्यकता होती है जो आपको वास्तव में अपने परीक्षण के लिए चाहिए। एक निर्माता-आधारित DI के साथ आपको उनमें से सभी 10 को निर्दिष्ट करने की आवश्यकता है, भले ही 7 अप्रयुक्त हों।
विल्क-

4
@ विलक्स- यदि आपके पास कई अप्रयुक्त कंस्ट्रक्टर पैरामीटर हैं, तो संभावना है कि आपका वर्ग एकल जिम्मेदारी सिद्धांत का उल्लंघन कर रहा है।
आरबी।

79

कल्पना कीजिए कि आप एक कारखाने में मजदूर हैं जो जूते बनाता है

आप जूतों को असेंबल करने के लिए जिम्मेदार हैं और इसलिए आपको ऐसा करने के लिए बहुत सारी चीजों की आवश्यकता होगी।

  • चमड़ा
  • मापने का टेप
  • गोंद
  • नाखून
  • हथौड़ा
  • कैंची
  • जूता लेस

और इसी तरह।

आप कारखाने में काम कर रहे हैं और आप शुरू करने के लिए तैयार हैं। आपके पास आगे बढ़ने के निर्देशों की सूची है, लेकिन आपके पास अभी तक कोई भी सामग्री या उपकरण नहीं है।

एक सेवा लोकेटर एक फोरमैन की तरह होता है जो आपकी जरूरत के हिसाब से मदद कर सकता है।

आप हर बार जब आपको किसी चीज़ की ज़रूरत होती है, तो आप सेवा लोकेटर से पूछते हैं और वे आपके लिए इसे खोजने निकल जाते हैं। सेवा लोकेटर समय से पहले के बारे में बताया गया है कि आप क्या माँग रहे हैं और इसे कैसे पा सकते हैं।

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

सेवा लोकेटर

एक निर्भरता इंजेक्शन (DI) कंटेनर एक बड़े बक्से की तरह है जो दिन की शुरुआत में हर किसी की जरूरत के अनुसार भर जाता है।

कारखाना शुरू होता है के रूप में, बिग बॉस के रूप में जाना संरचना रूट कंटेनर पकड़ लेता है और सब कुछ बाहर हाथ लाइन प्रबंधकों

रेखा प्रबंधकों के पास अब दिन के लिए अपने कर्तव्यों का पालन करने की आवश्यकता है। वे वही लेते हैं जो उनके पास है और उनके अधीनस्थों के लिए जो आवश्यक है उसे पास करते हैं।

यह प्रक्रिया जारी रहती है, निर्भरता के साथ उत्पादन की रेखा नीचे गिरती है। आखिरकार आपके फोरमैन के लिए सामग्रियों और उपकरणों का एक कंटेनर दिखाई देता है।

आपका फोरमैन अब आपके और अन्य श्रमिकों के लिए ठीक वही चीज़ों का वितरण करता है, जो आप भी उनसे माँगते हैं।

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

निर्भरता इंजेक्शन कंटेनर


45
यह उन 2 चीज़ों में से एक उत्कृष्ट विवरण है, सुपर गुड लुकिंग आरेख भी! लेकिन यह "क्यों एक दूसरे पर एक का चयन" के सवाल का जवाब नहीं देता है?
मैथ्यू एम।

21
"आप बेहतर उम्मीद करेंगे कि आप कुछ अप्रत्याशित न पूछें। हालांकि यदि लोकेटर को किसी विशेष उपकरण या सामग्री के बारे में समय से पहले सूचित नहीं किया गया है" लेकिन यह भी डि कंटेनर का सच हो सकता है।
केनेथ के।

5
@FrankHopkins यदि आप अपने DI कंटेनर के साथ एक इंटरफ़ेस / क्लास रजिस्टर करना छोड़ते हैं, तो आपका कोड अभी भी संकलित होगा, और यह रनटाइम में तुरंत विफल हो जाएगा।
केनेथ के।

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

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

10

वेब को डराते समय मैंने कुछ अतिरिक्त अंक प्राप्त किए हैं:

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

4

मैं इस पार्टी में देर से आ रहा हूं लेकिन मैं विरोध नहीं कर सकता।

कंटेनर के साथ निर्भरता इंजेक्शन का उपयोग करने और सेवा लोकेटर का उपयोग करने के बीच क्या अंतर है?

कभी-कभी कोई नहीं। इससे क्या फर्क पड़ता है कि क्या पता है।

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

क्या इसका मतलब है कि यदि आप सेवा लोकेटर से बचना चाहते हैं तो आप कंटेनर का उपयोग नहीं कर सकते? नहीं, आपको केवल कंटेनर के बारे में जानने से ग्राहकों को रखना होगा। महत्वपूर्ण अंतर यह है कि आप कंटेनर का उपयोग कहां करते हैं।

कहते Clientहैं कि जरूरत है Dependency। कंटेनर एक है Dependency

class Client { 
    Client() { 
        BeanFactory beanfactory = new ClassPathXmlApplicationContext("Beans.xml");
        this.dependency = (Dependency) beanfactory.getBean("dependency");        
    }
    Dependency dependency;
}

हमने सेवा लोकेटर पैटर्न का अनुसरण किया है क्योंकि Clientपता है कि कैसे खोजना है Dependency। यकीन है कि यह एक हार्ड कोडित का उपयोग करता है, ClassPathXmlApplicationContextलेकिन भले ही आप इंजेक्ट करते हैं कि आपके पास अभी भी एक सेवा लोकेटर है क्योंकि Clientकॉल beanfactory.getBean()

सेवा लोकेटर से बचने के लिए आपको इस कंटेनर को छोड़ना नहीं है। आपको बस इसे स्थानांतरित करना है Clientताकि Clientइसके बारे में पता न चले ।

class EntryPoint { 
    public static void main(String[] args) {
        BeanFactory beanfactory = new ClassPathXmlApplicationContext("Beans.xml");
        Client client = (Client) beanfactory.getBean("client");

        client.start();
    }
}

<?xml version="1.0" encoding="UTF-8"?>
 <beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
  http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

    <bean id="dependency" class="Dependency">
    </bean>

    <bean id="client" class="Client">
        <constructor-arg value="dependency" />        
    </bean>
</beans>

ध्यान दें कि Clientअब कंटेनर के मौजूद होने का कोई पता नहीं है:

class Client { 
    Client(Dependency dependency) { 

        this.dependency = dependency;        
    }
    Dependency dependency;
}

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

सभी स्थिर निर्माण को कंटेनरों में ले जाता है एक्सएमएल अभी तक आपके सभी ग्राहकों को इस बात से अनभिज्ञ रखता है कि उनकी निर्भरता कैसे पाई जाए।

लेकिन मुख्य अभी भी निर्भरता का पता लगाने का तरीका जानता है! हाँ यह करता है। लेकिन उस ज्ञान को इधर-उधर न फैलाकर आप सेवा लोकेटर की मुख्य समस्या से बच गए हैं। एक कंटेनर का उपयोग करने का निर्णय अब एक ही स्थान पर किया गया है और सैकड़ों ग्राहकों को फिर से लिखे बिना बदला जा सकता है।


1

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

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

आइए निम्न वर्ग को देखें:

public class MySpecialStringWriter
{
  private readonly IOutputProvider outputProvider;
  public MySpecialFormatter(IOutputProvider outputProvider)
  {
    this.outputProvider = outputProvider;
  }

  public void OutputString(string source)
  {
    this.outputProvider.Output("This is the string that was passed: " + source);
  }
}

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

सेवा लोकेटर के साथ एक ही वर्ग को देखें:

public class MySpecialStringWriter
{
  private readonly ServiceLocator serviceLocator;
  public MySpecialFormatter(ServiceLocator serviceLocator)
  {
    this.serviceLocator = serviceLocator;
  }

  public void OutputString(string source)
  {
    this.serviceLocator.OutputProvider.Output("This is the string that was passed: " + source);
  }
}

अब मैंने सेवा लोकेटर को निर्भरता के रूप में जोड़ा है। यहाँ समस्याएं हैं जो तुरंत स्पष्ट हैं:

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

तो हम सेवा लोकेटर को एक स्थिर वर्ग क्यों नहीं बनाते हैं? चलो एक नज़र डालते हैं:

public class MySpecialStringWriter
{
  public void OutputString(string source)
  {
    ServiceLocator.OutputProvider.Output("This is the string that was passed: " + source);
  }
}

यह बहुत सरल है, है ना?

गलत।

बता दें कि IOutputProvider बहुत लंबे समय से चल रही वेब सेवा द्वारा कार्यान्वित किया जाता है जो दुनिया भर के पंद्रह अलग-अलग डेटाबेस में स्ट्रिंग लिखती है और पूरा होने में बहुत लंबा समय लेती है।

आइए इस वर्ग का परीक्षण करने का प्रयास करें। हमें परीक्षण के लिए IOutputProvider के एक अलग कार्यान्वयन की आवश्यकता है। हम परीक्षण कैसे लिखते हैं?

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

तो अब आप या तो साथ छोड़ दिए गए हैं) एक परीक्षण जो असंबंधित ServiceLocator वर्ग में अप्रिय कोड परिवर्तन का कारण बन रहा है; या बी) कोई परीक्षण नहीं। और आप एक कम लचीला समाधान के साथ छोड़ दिया है।

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

सीधे शब्दों में कहें तो सर्विस लोकेटर एक आवेदन में युग्मन बढ़ाते हैं और अन्य डेवलपर्स को अत्यधिक युग्मित कोड लिखने के लिए प्रोत्साहित करते हैं


सेवा लोकेटर (SL) और निर्भरता इंजेक्शन (DI) दोनों समान शिष्टाचार में एक ही मुद्दे को हल करते हैं। फर्क सिर्फ इतना है कि अगर आपके "कह रहे हैं" DI या "पूछ" निर्भरता के लिए SL।
मैथ्यू व्हाइट

@MatthewWhited मुख्य अंतर एक सेवा लोकेटर के साथ आपके द्वारा लिए गए निहित निर्भरता की संख्या है। और इससे कोड की दीर्घकालिक स्थिरता और स्थिरता पर भारी अंतर पड़ता है।
स्टीफन

यह वास्तव में नहीं है। आपके पास या तो निर्भरता की एक ही संख्या है।
मत्ती व्हीट

शुरू में हाँ, लेकिन आप एक सेवा लोकेटर के साथ निर्भरता ले सकते हैं बिना यह एहसास किए कि आप निर्भरता ले रहे हैं। जो इस कारण के एक बड़े हिस्से को हरा देता है कि हम पहली जगह पर निर्भरता उलटा क्यों करते हैं। एक वर्ग गुण ए और बी पर निर्भर करता है, दूसरा बी और सी पर निर्भर करता है। अचानक सेवा लोकेटर एक देव वर्ग बन जाता है। DI कंटेनर नहीं है और दो वर्ग क्रमशः ए और बी और बी और सी पर ही निर्भर हैं। यह उन्हें सौ गुना आसान बनाता है। सेवा लोकेटर इस बात से कपटी हैं कि वे DI के समान दिखाई देते हैं लेकिन वे नहीं हैं।
स्टीफन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.