जैसा कि मैंने समझाया है, खुले / बंद सिद्धांत में कहा गया है कि एक बार लिखित कोड को संशोधित नहीं किया जाना चाहिए (बग फिक्स से अलग)। लेकिन अगर मेरे व्यावसायिक नियम बदलते हैं तो क्या मुझे उन परिवर्तनों को लागू करने वाले कोड को संशोधित नहीं करना चाहिए? मुझे संदेह है कि मैं इस बारे में कुछ नहीं समझ रहा हूं कि सिद्धांत कैसे है क्योंकि यह मेरे लिए समझ में नहीं आता है।
जवाबों:
यह समझाने के लिए ठोस सिद्धांतों में शायद सबसे कठिन है। मुझे कोशिश करने दो। कल्पना कीजिए कि आपने एक इनवॉइस क्लास लिखी है जो पूरी तरह से काम करती है और इसमें कोई बग नहीं है। यह एक चालान का एक पीडीएफ बनाता है।
फिर कोई कहता है कि वे इसमें लिंक के साथ एक HTML चालान चाहते हैं। आप इस अनुरोध को पूरा करने के लिए चालान में कोई कोड नहीं बदलते हैं। इसके बजाय, आप एक और वर्ग बनाते हैं, HTMLInvoice, वही करता है जो वे अब चाहते हैं। आप विरासत का लाभ उठाते हैं ताकि आपको HTMLInvoice में बहुत सारे डुप्लिकेट कोड न लिखने पड़ें।
पुराना कोड जो पुराने इनवॉइस का उपयोग कर रहा था वह किसी भी तरह से टूटा हुआ या वास्तव में प्रभावित नहीं हुआ है। नया कोड HTMLInvoice का उपयोग कर सकता है। (यदि आप Liskov सबस्टिबिलिटी, सॉलिड के L भी करते हैं , तो आप मौजूदा कोड के लिए HTMLInvoice इंस्टेंस दे सकते हैं, जो इनवॉइस इंस्टैंस की अपेक्षा कर रहा है।) हर कोई खुशी के साथ कभी भी रहता है।
चालान संशोधन के लिए बंद है, विस्तार के लिए खुला है। और आपको इनवॉइस को काम करने के लिए अग्रिम में ठीक से लिखना होगा, btw।
क्या आपने ObjectMentor पर चाचा बॉब के दोस्तों द्वारा ओपन-क्लोज्ड सिद्धांत लेख पढ़ा है? मुझे लगता है कि यह बेहतर स्पष्टीकरणों में से एक है।
ऑब्जेक्ट ओरिएंटेड डिज़ाइन के साथ कई ह्यूरिस्टिक्स जुड़े हुए हैं। उदाहरण के लिए, "सभी सदस्य चर निजी होने चाहिए", या "वैश्विक चर से बचा जाना चाहिए", या "रन टाइम प्रकार की पहचान (आरटीटीआई) का उपयोग करना खतरनाक है"। इन उत्तराधिकारियों का स्रोत क्या है? क्या उन्हें सच बनाता है? क्या वे हमेशा सच होते हैं? यह स्तंभ डिजाइन सिद्धांत की जांच करता है जो इन उत्तराधिकारियों को रेखांकित करता है - खुले-बंद सिद्धांत।
जैसा कि इवर जैकबसन ने कहा था: “उनके जीवन चक्र के दौरान सभी प्रणालियाँ बदल जाती हैं। यह तब ध्यान में रखना चाहिए जब विकासशील प्रणालियाँ पहले संस्करण की तुलना में अधिक समय तक चलने की उम्मीद करती हैं। ”हम ऐसे डिजाइन कैसे बना सकते हैं जो परिवर्तन के चेहरे पर स्थिर हों और जो पहले संस्करण की तुलना में अधिक समय तक चलेंगे? बर्ट्रेंड मेयर ने हमें बहुत पहले 1988 तक मार्गदर्शन दिया जब उन्होंने अब तक के प्रसिद्ध खुले-बंद सिद्धांत को गढ़ा। उसे विमुग्ध करने के लिए:
सॉफ़्टवेयर ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) शोषण के लिए खुला होना चाहिए, विवरण के लिए बंद किया गया।
जब एक कार्यक्रम के लिए एक एकल परिवर्तन निर्भर मॉड्यूल के लिए परिवर्तनों के एक झरना में परिणाम होता है, तो यह कार्यक्रम अवांछनीय विशेषताओं को प्रदर्शित करता है जिसे हम "खराब" डिजाइन के साथ जोड़कर आए हैं। कार्यक्रम नाजुक, कठोर, अप्रत्याशित और अप्राप्य हो जाता है। खुले-बंद सिद्धांत इस पर बहुत ही सीधे तरीके से हमला करते हैं। यह कहता है कि आपको ऐसे मॉड्यूल डिजाइन करने चाहिए जो कभी नहीं बदलते । जब आवश्यकताएं बदलती हैं, तो आप नए कोड को जोड़कर ऐसे मॉड्यूल के व्यवहार का विस्तार करते हैं, न कि पुराने कोड को बदलकर जो पहले से ही काम करता है।
विवरण
खुले-बंद सिद्धांत के अनुरूप मॉड्यूल में दो प्राथमिक गुण होते हैं।
- वे "एक्सटेंशन के लिए ओपन" हैं।
इसका मतलब है कि मॉड्यूल के व्यवहार को बढ़ाया जा सकता है। कि हम मॉड्यूल को नए और अलग-अलग तरीकों से व्यवहार में परिवर्तन कर सकते हैं जैसे कि आवेदन में परिवर्तन, या नए अनुप्रयोगों की जरूरतों को पूरा करने के लिए।- वे "संशोधन के लिए बंद हैं"।
इस तरह के एक मॉड्यूल का स्रोत कोड इनवॉयलेट है। किसी को भी स्रोत कोड परिवर्तन करने की अनुमति नहीं है।ऐसा लगता है कि ये दोनों विशेषताएँ एक-दूसरे के साथ हैं। किसी मॉड्यूल के व्यवहार का विस्तार करने का सामान्य तरीका उस मॉड्यूल में परिवर्तन करना है। एक मॉड्यूल जिसे बदला नहीं जा सकता है उसे सामान्य रूप से एक निश्चित व्यवहार माना जाता है। इन दो विरोधी विशेषताओं को कैसे हल किया जा सकता है?
अमूर्त कुंजी है ...
केट ग्रेगरी द्वारा जवाब बहुत अच्छा है, लेकिन एक अलग स्थिति है जहाँ एक नया आवश्यकता मौजूदा में एक अपेक्षाकृत छोटे परिवर्तन से संतुष्ट किया जा सकता है पर विचार Invoiceवर्ग। उदाहरण के लिए, मान लें कि इनवॉइस पीडीएफ में एक नया फ़ील्ड जोड़ा जाना चाहिए। OCP के अनुसार, हमें अभी भी एक नया उपवर्ग बनाना चाहिए, भले ही कोड की कुछ पंक्तियों को बदलकर मौजूदा कार्यान्वयन में नया क्षेत्र जोड़ा जा सकता है।
मेरी समझ में, ओसीपी 80 और 90 के दशक की शुरुआत की वास्तविकता को दर्शाता है, जहां परियोजनाएं अक्सर संस्करण नियंत्रण का भी उपयोग नहीं करती थीं, बहुत कम स्वचालित प्रतिगमन परीक्षण या परिष्कृत रिफैक्टरिंग उपकरणों का लाभ था। OCP कोड तोड़ने के जोखिम से बचने का एक प्रयास था जिसे मैन्युअल रूप से परीक्षण किया गया था और उत्पादन में डाल दिया गया था। आज, हमारे पास काम करने वाले सॉफ़्टवेयर (अर्थात्, संस्करण नियंत्रण प्रणाली, टीडीडी और स्वचालित परीक्षण और रिफैक्टिंग टूल) को तोड़ने के जोखिम को प्रबंधित करने के बेहतर तरीके हैं।
व्यक्तिगत रूप से मुझे लगता है कि इस सिद्धांत को एक चुटकी नमक के साथ लिया जाना चाहिए। कोड ऑर्गेनिक है, कारोबार बदलते हैं और समय की जरूरत के अनुसार कोड बदलते हैं।
मुझे इस तथ्य के बारे में अपना सिर प्राप्त करना बहुत मुश्किल है कि अमूर्तता महत्वपूर्ण है। क्या होगा अगर अमूर्त मूल रूप से गलत था? क्या होगा यदि व्यवसाय फ़ंक्शन में काफी बदलाव आया है?
यह सिद्धांत अनिवार्य रूप से सुनिश्चित करता है कि मूल इरादों और एक डिजाइन के व्यवहार को कभी नहीं बदलना चाहिए। यह शायद उन लोगों के लिए काम करता है जिनके पास सार्वजनिक एपीआई है और उनके ग्राहकों को नई रिलीज, और कुछ अन्य एज-केस रखने में परेशानी होती है। हालांकि, अगर कोई कंपनी सभी कोड का मालिक है, तो मैं इस सिद्धांत को चुनौती देता हूं।
अपने कोड का अच्छा परीक्षण कवरेज होने से आपके कोड आधार को रीफ्रैक्टिंग करना चाहिए। इसका मतलब है कि सामान गलत होना ठीक है - आपके परीक्षण आपको बेहतर डिजाइन के लिए मार्गदर्शन करने में मदद करेंगे।
यह कहते हुए कि, यदि कोई परीक्षण नहीं है, तो यह सिद्धांत ध्वनि है।