"निर्भरता उलटा सिद्धांत" (डीआईपी) और "डिजाइन टू इंटरफेस सिद्धांत" एक ही सिद्धांत व्यक्त करते हैं? यदि नहीं, तो क्या अंतर होगा?क्या "निर्भरता उलटा" और "इंटरफेस के लिए डिजाइन" समान सिद्धांत हैं?
संपादित
को स्पष्ट और संदर्भ थोड़ा को कम करने के लिए: इंटरफ़ेस द्वारा मैं एक कार्यक्रम इंटरफ़ेस मतलब है, एक जावा interface या एक शुद्ध सार आधार वर्ग C++ की तरह। कोई अन्य 'अनुबंध' शामिल नहीं है।
"अनुबंध द्वारा डिजाइन" और "निर्भरता इंजेक्शन" बहुत करीबी से संबंधित हैं, लेकिन अमूर्तता के विभिन्न स्तर हैं। "अनुबंध द्वारा डिजाइन" एक बहुत ही सामान्य डिजाइन सिद्धांत है, जिसे विभिन्न तकनीकों द्वारा समर्थित किया जा सकता है; एक ऐसी भाषा में जिसमें जावा-जैसी क्लास सिस्टम है, आप एक तकनीक कंक्रीट क्लास निर्भरताओं से बचने के लिए इंटरफेस का उपयोग करना है। "निर्भरता इंजेक्शन" एक और तकनीक है, जो अक्सर कार्य करने के लिए इंटरफेस के अस्तित्व पर निर्भर करती है (लेकिन हमेशा ऐसा करने की आवश्यकता नहीं होती है - यह भाषा पर निर्भर करता है)। मैं कहूंगा कि "निर्भरता इंजेक्शन" "अनुबंध द्वारा डिजाइन" के सिद्धांत का समर्थन करता है।
इंटरफेस के लिए डिज़ाइन (design by contract के रूप में) निर्भरता उलटा समर्थन करता है। दोनों युग्मन को कम करते हैं। हालांकि:
दृष्टिकोण एक-दूसरे के पूरक होते हैं।
ए (शुद्ध) अमूर्त बेस क्लास = इंटरफ़ेस। – eljenso
और वस्तु निर्माण/जीवनसाथी के बारे में डीआईपी बात कहां है? हो सकता है कि "सृजन" या "जीवन चक्र" श्रेणी में आने वाले कुछ पैटर्न डीआईपी के साथ अच्छी तरह से जाएं, लेकिन निश्चित रूप से सिद्धांत के रूप में डीआईपी इस पर ध्यान नहीं देता है और यह डिजाइन के बारे में है। – eljenso
निर्भरता * उलटा * और निर्भरता * इंजेक्शन * एक ही चीज़ होने से बहुत दूर हैं। –
मैं सिर्फ another question very similar to this one पर डेरेक ग्रीर को पिच करना और उद्धृत करना चाहता था, क्योंकि यह मेरी राय में, इस सवाल का जवाब अच्छी तरह से करता है।
"क्या निर्भरता उलट सिद्धांत का उल्लेख नहीं करता इंटरफेस (जैसे
MyService → [ILogger ⇐ Logger]) के उपयोग के माध्यम निर्भरता सार संक्षेप की साधारण बात है।"
इस निर्भरता के विशिष्ट कार्यान्वयन विस्तार से एक घटक अलग करता है, यह उपभोक्ता और निर्भरता के बीच के रिश्ते (जैसे [MyService → IMyServiceLogger] ⇐ Logger) को पलट नहीं है। "
निर्भरता उलट अपने उच्च स्तर मॉड्यूल सुनिश्चित है निचले स्तर के मॉड्यूल पर निर्भर न करें। इसलिए आपका एप्लिकेशन तर्क आपके व्यापार मॉडल या व्यापार तर्क पर निर्भर नहीं है। चिंताओं का स्पष्ट पृथक्करण है।
सिद्धांत बताता है कि आपका एप्लिकेशन आपके व्यापार स्तर को परिभाषित करता है और एक इंटरफेस का मालिक है लागू करना चाहिए। यह जिस तरह से आपका व्यवसाय स्तर आपके एप्लिकेशन के परिभाषित इंटरफ़ेस पर निर्भर करता है। इस प्रकार निर्भरता उलटा हुआ है।
यदि आपके पास अब तीन एप्लिकेशन हैं, तो प्रत्येक व्यवसाय के स्तर पर लागू किए गए अपने स्वयं के इंटरफेस के साथ आपके व्यवसाय के स्तर को बदल सकते हैं, और जब तक वे इंटरफेस को लागू करते हैं, तब तक आपके आवेदन कोई भी बुद्धिमान नहीं होते हैं।
इस सिद्धांत का एक अच्छा जावा उदाहरण और कैसे इस तरह के एक परियोजना संरचित किया जाएगा यहां पाया जा सकता है, अपनी वेबसाइट पर: http://www.jeenisoftware.com/maven-dip-principle-example/
निर्भरता उलट इंटरफेस करने डिजाइन के बारे में इतना नहीं है, हालांकि वह यह है कि क्या हो रहा है , यह एक सेवा को लागू करने के बारे में अधिक है। दूसरे शब्दों में एक तरह की सेवा उन्मुख डिजाइन पैटर्न।
आपका मतलब निर्भरता इंजेक्शन (नियंत्रण का उर्फ उलटा) है? – tehvan
मुझे "डिज़ाइन टू इंटरफेस सिद्धांत" के लिए Google पर कोई जानकारी नहीं मिल रही है - क्या आप इसका समझा सकते हैं कि इसका क्या मतलब है? – Trumpi
आप शायद "अनुबंध द्वारा डिजाइन" – troelskn