निर्भरता उलटा सिद्धांत बनाम "एक इंटरफेस के लिए कार्यक्रम, एक कार्यान्वयन नहीं"


12

मैं यह समझने की कोशिश कर रहा हूं कि डिपेंडेंसी इनवर्सन प्रिंसिपल "प्रोग्राम से इंटरफ़ेस तक नहीं, कार्यान्वयन" सिद्धांत से भिन्न है।

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

लेकिन मुझे समझ नहीं आ रहा है कि डिपेंडेंसी इनवर्सन प्रिंसिपल "प्रोग्राम से लेकर इंटरफ़ेस तक, कार्यान्वयन नहीं" सिद्धांत से अलग है।

मैंने वेब पर कई स्थानों पर डीआईपी के बारे में पढ़ा, और इससे मेरा भ्रम दूर नहीं हुआ। मैं अभी भी नहीं देखता कि दोनों सिद्धांत एक दूसरे से कैसे भिन्न हैं। आपकी सहायता के लिए धन्यवाद।

जवाबों:


26

"एक इंटरफेस के लिए कार्यक्रम" का अर्थ है अपने काम करने के लिए एक ठोस प्रकार पर निर्भर नहीं है , लेकिन यह निर्दिष्ट नहीं करता है कि आपको अपनी निर्भरता कैसे प्राप्त करनी चाहिए।

"निर्भरता उलटा सिद्धांत" कहता है कि एक वस्तु को अपनी निर्भरता के निर्माण को नियंत्रित नहीं करना चाहिए, इसे बस यह निर्भर करना चाहिए कि किस निर्भरता की आवश्यकता है और कॉलर को इसे प्रदान करने दें । लेकिन यह निर्दिष्ट नहीं करता है कि निर्भरता एक ठोस प्रकार या एक इंटरफ़ेस होनी चाहिए।

मैं कुछ C # कोड के साथ अंतरों का वर्णन करूँगा।

निम्न उदाहरण एक ठोस प्रकार पर निर्भर करता है, और यह नियंत्रित करता है कि यह स्वयं की निर्भरता का निर्माण है। यह न तो "इंटरफ़ेस के लिए प्रोग्राम" और न ही "निर्भरता व्युत्क्रम" का अनुसरण करता है :

public class ThingProcessor
{
    MyThing _myThing;

    public ThingProcessor()
    {
        _myThing = new MyThing();
    }

    public void DoSomething()
    {
        _myThing.DoIt();
    }
}

निम्नलिखित उदाहरण एक इंटरफ़ेस पर निर्भर करता है, लेकिन यह नियंत्रित करता है कि यह स्वयं की निर्भरता का निर्माण है। यह "एक इंटरफ़ेस के लिए प्रोग्राम" का अनुसरण करता है, लेकिन "निर्भरता व्युत्क्रम" नहीं:

public class ThingProcessor
{
    IMyThing _myThing;

    public ThingProcessor()
    {
        _myThing = ThingFactory.GiveMeANewMyThing();
    }

    public void DoSomething()
    {
        _myThing.DoIt();
    }
}

निम्नलिखित उदाहरण एक ठोस प्रकार पर निर्भर करता है, लेकिन यह इसकी निर्भरता बनाने और इसे पारित करने के लिए कहता है। यह "निर्भरता व्युत्क्रम" का अनुसरण करता है, लेकिन "इंटरफ़ेस का प्रोग्राम" नहीं:

public class ThingProcessor
{
    MyThing _myThing;

    public ThingProcessor(MyThing myThing)
    {
        _myThing = myThing;
    }

    public void DoSomething()
    {
        _myThing.DoIt();
    }
}

निम्नलिखित उदाहरण एक इंटरफेस पर निर्भर करता है, और यह अपनी निर्भरता बनाने और इसे पारित करने के लिए कहता है। यह "निर्भरता व्युत्क्रम" और "इंटरफ़ेस के लिए प्रोग्राम " दोनों का अनुसरण करता है :

public class ThingProcessor
{
    IMyThing _myThing;

    public ThingProcessor(IMyThing myThing) // using an interface
    {
        _myThing = myThing;
    }

    public void DoSomething()
    {
        _myThing.DoIt();
    }
}

1
अंतर का उत्कृष्ट चित्रण।
रोरी हंटर

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

1
@ यूफोरिक मैं डिपेंडेंसी इनवर्जन प्रिंसिपल के बारे में बात कर रहा हूं, जो कि एक अमूर्त अवधारणा है, डिपेंडेंसी इंजेक्शन को ठोस कार्यान्वयन उदाहरण के रूप में उपयोग करके। मुझे फर्क समझ आता है।
एरिक किंग

1
@EricKing तब आपको स्पष्ट रूप से कहना चाहिए कि "उत्तर पर निर्भरता के सिद्धांत" के बजाय आपके उत्तर में "..." लिखा है, जो स्पष्ट रूप से गलत है यदि आप मेरा उत्तर पढ़ते हैं।
जश्न

1
मैं व्यंजना से सहमत हूं। निर्भरता उलटा सिद्धांत कहता है कि कोड की उच्च-स्तरीय परतें कोड के निचले-स्तर के टुकड़ों पर निर्भर होनी चाहिए, न कि इसके विपरीत। ईजी PrintStreamद्वारा स्थापित इंटरफेस पर निर्भर होना चाहिए ByteOutputStream। निर्भरता इंजेक्शन में इस बात का जिक्र नहीं है कि कौन किस पर निर्भर होना चाहिए।
डोभाल

5

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

  • उच्च स्तर के मॉड्यूल को निम्न-स्तर के मॉड्यूल पर निर्भर नहीं होना चाहिए। दोनों को अमूर्तता पर निर्भर होना चाहिए।
  • विवरण कभी भी विवरण पर निर्भर नहीं होना चाहिए। विवरण सार पर निर्भर होना चाहिए।

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


यह स्वीकार किया गया उत्तर होना चाहिए, अन्य सबसे अधिक मत दिया गया उत्तर भ्रामक है
समान डायब्स

2

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

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

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