खुला/बंद सिद्धांत किसी वस्तु या विधि में प्रतिगमन को रोकने के बारे में प्रतीत होता है। यह देखते हुए कि आपका कोड परीक्षण द्वारा कवर किया गया है क्योंकि आप बीडीडी का अभ्यास कर रहे हैं, यह एक अनावश्यक आवश्यकता प्रतीत होता है। इसके अलावा यह भाषा स्तर की बजाय एपीआई स्तर पर एक्स्टेंसिबिलिटी की आवश्यकता के द्वारा अतिरिक्त जटिलता पेश करता प्रतीत होता है।क्या बीडीडी का उपयोग करते समय खुले/बंद सिद्धांत का पालन करने के कोई लाभ हैं?
बिल्कुल लाभ हैं। वास्तव में, दो प्रधानाचार्य (बीडीडी और ओपन/बंद) विभिन्न उद्देश्यों के लिए डिजाइन किए गए हैं। बीडीडी को विकास प्रक्रिया का नेतृत्व करने के लिए डिज़ाइन किया गया है, और यही वह जगह है जहां इसके लाभ महसूस किए जाते हैं (समय सारिणी को कम करना, उच्च गुणवत्ता कोड बनाना आदि)। खुली/बंद विकास प्रक्रिया में किया जाना है, लेकिन रखरखाव में मदद करें।
बीडीडी के लाभ समझने में आसान हैं। प्रारंभिक विकास के लिए छोटी समय सारिणी का मतलब पूरी तरह से परियोजना के लिए कम लागत है, है ना? गलत। The 60/60 Rule के आधार पर, परियोजना की लागत का 60% इसे बनाए रखने से है (और उस लागत का 60% पोस्ट-तैनाती के बाद आवश्यकताओं में परिवर्तन से है)। इसलिए प्रारंभिक विकास चरण के दौरान पैसे बचाने के लिए फायदेमंद है, लेकिन रखरखाव के दौरान बड़ी बचत होनी चाहिए।
और यही वह जगह है जहां ओपन/क्लोज़ प्रिंसिपल का भुगतान होगा। उस प्रिंसिपल का पालन करके, आप रखरखाव में अपने आप को बहुत समय बचाएंगे (क्योंकि आपको टूटा हुआ यूनिट टेस्ट ट्रैक करने की आवश्यकता नहीं है क्योंकि आप किसी विधि की कार्यक्षमता को बदलते हैं)।
और ओपन/क्लोज़ प्रिंसिपल इतने ज्यादा प्रतिगमन को रोकने के बारे में नहीं है क्योंकि यह एक बदलती एपीआई को रोक रहा है जो कि जारी रखना लगभग असंभव है। यदि आप ध्यान देते हैं, तो अच्छे एपीआई कभी नहीं बदलते हैं। वे बढ़ाया जा सकता है। भागों को बहिष्कृत किया जा सकता है। लेकिन आप setFoo(string bar) को कभी भी setFoo(int bar) पर नहीं देखते हैं। रोकने के लिए ओपन/क्लोज़ किया गया है ...
मैं समझता हूं कि आप क्यों अपना एपीआई बदलना नहीं चाहते हैं। जहां मैं इतना निश्चित नहीं हूं कि आप कक्षा के एपीआई में जोड़ना चाहते हैं। मुझे यकीन नहीं है कि मैंने सही तरीके से खुले/बंद कर दिए हैं, लेकिन ऐसा लगता है कि आपको बंद होने के बाद कक्षा को नहीं बदलना चाहिए। यदि ऐसा है तो ऐसा लगता है कि यह अन्य सिद्धांतों के साथ संघर्ष करता है जैसे कि रिफैक्टरिंग के माध्यम से प्रारंभिक और उभरते डिज़ाइन को अनुकूलित न करें। शायद मैं गलत हूं और यह केवल व्यक्तिगत तरीकों को बंद करने के लिए संदर्भित करता है? – opsb
@opsb: मुझे लगता है कि आपने इसे सही ढंग से grokked है। कक्षाओं के लिए लागू, खुले/बंद सिद्धांत कहते हैं, "आप जानते हैं कि आप कक्षा में नए तरीकों को कैसे जोड़ सकते हैं, और यह अभी भी पूरी तरह से पिछड़ा है- सभी मौजूदा कोड के साथ संगत? अच्छा, ऐसा मत करो। इसके बजाय, एक नई कक्षा बनाएं पुरानी कक्षा की सभी कार्यक्षमताओं के साथ-साथ और भी। यह नई कक्षा पुरानी कक्षा का उप-वर्ग हो सकती है यदि यह मदद करता है "। आप निर्भरता इंजेक्शन, रणनीति पैटर्न, और ऐसी किसी भी अन्य चाल के माध्यम से परिवर्तन की आवश्यकता का अनुमान लगाने की कोशिश भी कर सकते हैं, जिसके बारे में आप सोच सकते हैं कि उन्हें बदलने के लिए आपकी कक्षाओं को और अधिक लचीला बनाते हैं। –
यह नई कार्यक्षमता जोड़ने के लिए उप-वर्गीकरण है जो मुझे असहज बनाता है। यह देखते हुए कि आपकी एपीआई नहीं बदली है और आप केवल कार्यक्षमता जोड़ रहे हैं, मुझे विभाजित करने का लाभ नहीं दिख रहा है कि 2 वर्गों में एक वर्ग होना चाहिए यानी कि आपने अपने मौजूदा एपीआई में कोई रिग्रेशन सुनिश्चित नहीं किया है, वहां क्या औचित्य है एक डिजाइन का उपयोग करने के लिए जो प्रक्रिया में किसी भी अन्य बिंदु पर कम माना जाएगा। – opsb
फुर्तीली तकनीक का एक समूह है जो आपके स्वयं के संगठन के बाहर प्रकाशित एपीआई पर लागू नहीं होता है, क्योंकि यह सभी कोड को अपडेट करना असंभव है जो निर्भर करता है इंटरफ़ेस पर आप बदल रहे हैं। खुले/बंद उस तरह की चीज़ के लिए अधिक उपयुक्त है, मुझे लगता है, या आम तौर पर इंटरफेस (यदि कोई है) के लिए जो आप स्थायीता के लिए डिजाइन करते हैं। –