मैं ओपन क्लोज्ड प्रिंसिपल (OCP) और डिपेंडेंसी इनवर्जन प्रिंसीबल (DIP) के बीच के अंतर को समझने की कोशिश कर रहा था ।
अब तक इंटरनेट पर किए गए शोध के आधार पर, मैं इस निष्कर्ष पर पहुंचा हूं कि 'डीआईपी एक विकल्प है जिसके जरिए हम ओसीपी प्राप्त कर सकते हैं।'
क्या मैं इस पर सही हूँ?
क्या आप मुझे एक उदाहरण दे सकते हैं जो DIP का अनुसरण नहीं करता है लेकिन OCP का अनुसरण करता है?
जवाबों:
मैंने ओपन-क्लोज्ड सिद्धांत (ओसीपी) बनाम लिस्कोव के प्रतिस्थापन सिद्धांत (एलएसपी) पर पहले एक उत्तर लिखा था और वे दोनों सिद्धांत एक-दूसरे से बहुत संबंधित हैं, लेकिन अभी भी एक या दूसरे के होने के कुछ वंचित उदाहरणों के साथ वैचारिक रूप से भिन्न हैं। इस उत्तर की वजह से मैं केवल OCP पर थोड़ा-थोड़ा स्पर्श करूँगा और DIP में गहराई से और उस टिक को बनाता हूँ।
पहले विभिन्न सिद्धांतों को समझाते हुए OCP निर्भरता सिद्धांत (DIP) के साथ कैसे भिन्न होता है, इस पर चर्चा करने की कोशिश करते हैं।
अंकल बॉब के OOD के सिद्धांतों को पढ़कर आप पाएंगे कि DIP निम्नलिखित बताता है:
सार पर निर्भर करता है, न कि सहमति पर।
जावा में एक अमूर्तता बस interfaceऔर abstractखोजशब्दों के साथ हासिल की जाती है , जिसका अर्थ है कि आपके पास कुछ सॉफ़्टवेयर इकाई के लिए "अनुबंध" है जिसे कोड का पालन करना होगा। कुछ प्रोग्रामिंग भाषाओं में कोड के लिए स्पष्ट रूप से व्यवहार निर्धारित करने की सुविधा नहीं है, इसलिए संकलक को अनुबंध को लागू करने में आपकी मदद करने के बजाय अधिक अमूर्त तरीके से पालन करना पड़ता है। उदाहरण के लिए C ++ में आपके पास वर्चुअल मेथड्स और डायनेमिक प्रोग्रामिंग लैंग्वेजेस जैसे जावास्क्रिप्ट, आपको यह सुनिश्चित करना है कि आप ऑब्जेक्ट्स का उसी तरह उपयोग करें (हालांकि जावास्क्रिप्ट के मामले में इसे टाइपस्क्रिप्ट में बढ़ाया गया है जो आपकी मदद करने के लिए एक टाइप सिस्टम जोड़ता है। संविदाकार द्वारा सत्यापित अनुबंध लिखने के साथ)।
नाम में "उलटा" शब्द शामिल है क्योंकि पारंपरिक रूप से (प्रोग्रामिंग के पुराने अंधेरे युगों में y'know) आपने सॉफ्टवेयर संरचनाएं लिखी थीं जिनमें निम्न स्तर के मॉड्यूल के आधार पर उच्च स्तर के मॉड्यूल थे। जैसे यह ButtonAtKitchenएक KitchenLamp1और के लिए एक हैंडलिंग आदानों के लिए समझ में आया KitchenLamp2। दुर्भाग्य से उस सॉफ्टवेयर ने इसे बनाने के लिए ज़रूरत से ज़्यादा विशिष्ट बना दिया और ऑब्जेक्ट ग्राफ़ इस तरह दिखाई देगा:
इसलिए जब आप "अनुबंध" जोड़कर सॉफ़्टवेयर को अधिक सामान्य बनाते हैं। ध्यान दें कि ऑब्जेक्ट ग्राफ में तीर "दिशा" को कैसे प्रभावित करता है। किचन लैंप अब एक पर निर्भर हैं Button। दूसरे शब्दों में विवरण अब चारों ओर दूसरे तरीके के बजाय अमूर्तता पर निर्भर हैं।
इस प्रकार हमारे पास डीआईपी की एक अधिक सामान्य परिभाषा है, यह अंकल बॉब द्वारा डीआईपी के मूल लेख में भी विस्तृत है ।
A. उच्च स्तर के मॉड्यूल को निम्न स्तर के मॉड्यूल पर निर्भर नहीं होना चाहिए। दोनों को अमूर्तता पर निर्भर होना चाहिए। बी। विवरण विवरण पर निर्भर नहीं होना चाहिए। विवरण अमूर्तता पर निर्भर होना चाहिए।
अंकल बॉब के सिद्धांतों से निरंतर आपको पता चलता है कि OCP निम्नलिखित बताता है:
आपको इसे संशोधित किए बिना, कक्षाओं के व्यवहार का विस्तार करने में सक्षम होना चाहिए।
इसे प्राप्त करने का एक उदाहरण रणनीति पैटर्न को नियोजित करना है जहां एक Contextवर्ग संशोधनों के लिए बंद है (यानी आप इसे आंतरिक कोड बिल्कुल नहीं बदल सकते हैं) लेकिन यह निर्भरता (यानी रणनीति कक्षाओं) के माध्यम से विस्तार के लिए भी खुला है ।
अधिक सामान्य अर्थों में किसी भी मॉड्यूल को विस्तार बिंदुओं के माध्यम से एक्स्टेंसिबल बनाया जाता है।
नहीं , वास्तव में नहीं।
हालांकि वे दोनों अमूर्त चर्चा कर रहे हैं, वे वैचारिक रूप से अलग हैं। दोनों सिद्धांत अलग-अलग संदर्भों में देख रहे हैं, एक विशेष मॉड्यूल पर ओसीपी और कई मॉड्यूल पर डीआईपी। आप गैंग ऑफ़ फोर डिज़ाइन पैटर्न के साथ एक ही समय में दोनों को प्राप्त कर सकते हैं, लेकिन आप अभी भी पथ से दूर जा सकते हैं।
ऊपर उल्लिखित डीआईपी उदाहरण में, बटन और किचन लैंप के साथ, किचन लैंप में से कोई भी एक्स्टेंसिबल नहीं है (न ही वर्तमान में किसी भी आवश्यकता के बारे में बताते हुए उन्हें इसकी आवश्यकता है)। डिजाइन OCP को तोड़ रहा है लेकिन DIP का अनुसरण करता है ।
एक उल्टा (और एक विवादित) उदाहरण एक रसोई दीपक होगा जो एक्स्टेंसिबल होगा (विस्तार बिंदु के साथ कुछ ऐसा है LampShade) लेकिन बटन अभी भी लैंप पर निर्भर है । यह DIP को तोड़ रहा है लेकिन OCP का अनुसरण करता है ।
यह वास्तव में ऐसा कुछ है जो आप अक्सर उत्पादन कोड में देखते हैं, कि इसका कुछ हिस्सा एक सिद्धांत को तोड़ सकता है। बड़े सॉफ्टवेयर सिस्टम में (यानी ऊपर दिए गए उदाहरणों से कुछ भी बड़ा), आप एक सिद्धांत को तोड़ सकते हैं लेकिन दूसरे को आमतौर पर रखते हुए क्योंकि आपको कोड को सरल रखने की आवश्यकता होती है। यह मेरे दिमाग में है, छोटे और स्व-निहित मॉड्यूल के लिए ठीक है, क्योंकि वे सिंगल रिस्पॉन्सिबिलिटी प्रिंसिपल (एसआर) के संदर्भ में हैं।
एक बार कुछ मॉड्यूल जटिल हो जाता है, हालांकि आप सबसे अधिक संभावना को ध्यान में सभी सिद्धांतों के साथ यह देखो और नया स्वरूप या की जरूरत refactor कुछ प्रसिद्ध पैटर्न के लिए यह।