क्या वास्तविक-विश्व मान का प्रतिनिधित्व करने वाले निरंतर को अद्यतन करने के लिए ओपन-क्लोज्ड सिद्धांत का उल्लंघन है?

Question

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

क्या इस स्थिरांक को ठीक करने का कार्य ओपन-क्लोज्ड सिद्धांत का उल्लंघन दर्शाता है , क्योंकि यह बताता है कि एक वर्ग को संशोधन के लिए बंद कर दिया जाना चाहिए?

Comments

सॉफ्टवेयर बदलता है क्योंकि वास्तविक दुनिया बदल जाती है। दूसरी ओर एक कर प्रतिशत को स्थिर बनाना ओपन-क्लोज्ड सिद्धांत का इतना उल्लंघन नहीं है क्योंकि यह केवल एक अनभिज्ञ बात है। कर प्रतिशत एक स्पष्ट परिवर्तनशील वस्तु है जिसे रन टाइम पर बाध्य किया जाना चाहिए।

— रिचर्ड चेंबर्स

मैं रिचर्ड से पूरी तरह सहमत हूं। यदि आपको इस "स्थिर" को ठीक करने के लिए कोड बदलना है, तो OCP आपकी समस्याओं में से सबसे कम है।

— रॉबर्ट हार्वे

OCP का उल्लंघन किस प्रकार होता है यह अत्यधिक व्यक्तिपरक है और यह पूरी तरह से कुछ हद तक अप्रचलित है (चूंकि कार्यान्वयन विरासत में अब भी सबसे अच्छा अभ्यास नहीं है)। यह एक विशिष्ट प्रश्न है जहां आपको यह अनुमान लगाना होगा कि प्रश्न पूछने वाला व्यक्ति क्या सोचता है।

— रॉबर्ट ब्रूटिगम

@DocBrown: क्या "नई आवश्यकता" का गठन करता है? आप मुझे कुछ कोड दिखाते हैं, मैं नई आवश्यकताओं को इंगित कर सकता हूं, जिन्हें निश्चित रूप से कोड बदलने की आवश्यकता होगी, भले ही ओसीपी आप इसे कैसे बनाते हैं। इसलिए इस सवाल पर वापस जाएं: यदि डेवलपर ने व्यवसाय विशेषज्ञ से इसके बारे में पूछा, और हर दो साल में एक से अधिक बार कर की दर में बदलाव की उम्मीद नहीं थी, तो इसे विन्यास योग्य या इंजेक्शन योग्य बनाने का कोई मतलब नहीं है। बस इसे सरल रखें और जो आप जानते हैं उसकी तैयारी करें । और उन चीजों के लिए, निश्चित रूप से, इसे वर्ग के लिए बाहरी बनाएं। तो यह निर्भर करता है ।

— रॉबर्ट ब्रुटिगम 22

@ RobertBräutigam: मेरा कहना है, "OCP अनुरूप" के रूप में IMHO जैसी कोई चीज नहीं है, केवल "OCP अनुरूप ही कुछ श्रेणियों की आवश्यकताओं के संदर्भ में है"। निश्चित रूप से कुछ विषय हो सकते हैं कि किन श्रेणियों को एक घटक "ओसीपी अनुरूप" होना चाहिए। लेकिन इस प्रश्न में वर्णित मामले में, जिस तरह से मैं इसे समझता हूं, एक बदलती आवश्यकता को पहले ही पहचान लिया गया था, ताकि यह "आय वर्ग की गणना" स्पष्ट रूप से इस विशिष्ट आवश्यकता के संदर्भ में ओसीपी का पालन न करे।

— डॉक ब्राउन

Answer 1

OCP को बेहतर ढंग से समझा जा सकता है जब किसी विक्रेता द्वारा किसी प्रकार के ब्लैक-बॉक्स लाइब्रेरी में प्रदान किए गए वर्गों या घटकों के बारे में सोचते हुए, उपयोगकर्ताओं द्वारा उपयोग के लिए B, C और D इससे कोई फर्क नहीं पड़ता कि वास्तव में कक्षा का एकमात्र उपयोगकर्ता खुद ए) है।

यदि बी, सी और डी पुस्तकालय के स्रोत कोड के संशोधन की आवश्यकता के बिना, विभिन्न उपयोग के मामलों के लिए प्रदान की गई कक्षाओं का उपयोग या पुन: उपयोग कर सकते हैं, तो घटक ओसीपी ( उपयोग के मामलों की एक श्रेणी के संबंध में) को पूरा करता है । इसे प्राप्त करने के लिए अलग-अलग साधन हैं, जैसे

• वर्ग को अंतर्निहित बनाना (आमतौर पर टेम्पलेट विधि पैटर्न या रणनीति पैटर्न के साथ संयोजन के रूप में)

• निर्भरता इंजेक्शन के लिए "इंजेक्शन अंक" प्रदान करके

• वर्ग या घटक के लिए कॉन्फ़िगरेशन पैरामीटर प्रदान करके (उदाहरण के लिए, एक निर्माता पैरामीटर "कर प्रतिशत", जैसा कि आपके मामले में है, या कुछ अन्य कॉन्फ़िगरेशन तंत्र का उपयोग करके)

• शायद अन्य साधन, प्रोग्रामिंग भाषा या पारिस्थितिकी तंत्र पर निर्भर करते हैं

पाठ्य पुस्तकों में आपको जो विशिष्ट उदाहरण मिलते हैं, वे अक्सर पहले या दूसरे प्रकार के होते हैं (मुझे लगता है क्योंकि उन किताबों के लेखकों की नज़र में, तीसरा प्रकार बहुत ही मामूली है जो उल्लेख के लायक है)।

जैसा कि आप देख रहे हैं, इसका वेंडर ए (जैसे बग फिक्सिंग, ऑप्टिमाइज़ेशन या बैकवर्ड-कम्पैटिबल तरीके से नए फीचर्स जोड़ने के लिए) द्वारा सोर्स कोड के किसी भी बदलाव को मना करने से कोई लेना-देना नहीं है , जो OCP से काफी असंबंधित है। OCP इस बारे में है कि A किस प्रकार से इंटरफ़ेस और घटकों की ग्रैन्युलैरिटी को lib में डिज़ाइन करता है, इसलिए अलग-अलग रीस्यूज़ परिदृश्य (जैसे अलग-अलग कर दरों के साथ प्रतिधारण) स्वतः परिवर्तन के लिए आवश्यकताओं को प्रेरित नहीं करते हैं।

इसलिए दूसरों के बारे में आपको यहाँ बताया जाने के बावजूद, उत्तर स्पष्ट रूप से "हाँ" है , यह OCP का उल्लंघन होगा।

संपादित करें: लगता है कि किसी ने इस विषय के बारे में विस्तृत ब्लॉग पोस्ट लिखी है । हालांकि इसके कुछ हिस्सों को बेहतर तरीके से कहा जा सकता था (जैसा कि डेरेक एल्किंस ने बताया है), ऐसा लगता है कि लेखक आमतौर पर मेरी बात साझा करता है कि "ओसीपी को पूरा करना" कोई पूर्ण संपत्ति नहीं है, लेकिन एक ऐसी चीज जिसे केवल कुछ के संदर्भ में मूल्यांकन किया जा सकता है। आवश्यकता में परिवर्तन की श्रेणियां।

Comments

ठीक है, इसलिए OCP आपके द्वारा सूचीबद्ध तीन साधनों में से एक के साथ विभिन्न उपयोग के मामलों के लिए एक्स्टेंसिबल व्यवहार प्रदान करने के बारे में है, है ना? लेकिन क्या होगा अगर एक ओपी का उदाहरण निहित है कि कुछ मौलिक परिवर्तन के बारे में है? मुझे नहीं पता कि ओपी किस देश से है, लेकिन मेरे देश में कर की दर कुछ ऐसी है जो बहुत बार नहीं बदलती है। यह एक खराब उदाहरण था, लेकिन शायद इस बिंदु पर जोर देने के लिए इसे जानबूझकर एक स्थिर रूप से निकाला गया था। मुझे पूरा यकीन है कि यह विन्यास या विस्तार योग्य होने के लिए नहीं था। तो शायद सवाल यह था कि "विक्रेता ए" द्वारा स्रोत कोड के किसी भी परिवर्तन को मना करने से इसका कोई लेना-देना नहीं है।

— वादिम समोखिन

कम से कम मैंने इसे इस तरह समझा। गरीब आदमी जिसने अपने स्वीकृत उत्तर को हटा दिया, उसने या तो मुझे अनुमान लगाया। आपने इसे थोड़ा अलग कोण से देखा है - मैं आपकी बात समझता हूं और इससे सहमत हूं। लेकिन ऐसा लगता है कि सबसे बुद्धिमान टिप्पणी @Robert Bräutigam द्वारा दी गई थी। अब तक मुझे महसूस नहीं हुआ है कि OCP यह व्यक्तिपरक है।

— वादिम समोखिन

मुझे लगता है कि अगर मुझे कभी भी एक ही सवाल पूछा जाता है, तो एक सवाल है जिसका मुझे जवाब में पूछना चाहिए: "क्या वह व्यवहार किसी तरह से होना चाहिए या किसी तरह से कॉन्फ़िगर होना चाहिए?"। यदि हाँ - एक वर्ग के प्रत्यक्ष संशोधन की तुलना में स्वयं OCP का उल्लंघन है। यदि नहीं - OCP की तुलना में केवल उस स्थिति में लागू नहीं है।

— वादिम समोखिन

@Zadadlo: मुझे लगता है कि अगर कोई घटक आवश्यकताओं के वर्ग के लिए OCP पूरा करता है, तो बहुत व्यक्तिपरक नहीं है - ज्यादातर मामलों में यह बहुत स्पष्ट है कि अगर किसी नई आवश्यकता के लिए किसी घटक के स्रोत कोड के संशोधन की आवश्यकता होती है, या यदि घटक इस आवश्यकता का समर्थन करता है "इसे लागू करने के लिए संभावित दृष्टिकोण पहले 3 के लिए प्रतिबंधित नहीं हैं, जिसका अर्थ है कि मैंने सूचीबद्ध किया है। मेरा संपादन देखें। आपकी विषय-वस्तु की धारणा का कारण हो सकता है क्योंकि ओसीपी में केवल एक भ्रामक नाम है और बहुत सारी पाठ्यपुस्तकों में बहुत बुरा समझाया गया है।

— डॉक्टर ब्राउन

इस विषय पर मेरी धारणा इस तथ्य के कारण थी कि मैं पूरी तरह से समझ नहीं पाया था कि आपने क्या कहा - लेकिन मैं अब करता हूं, मुझे लगता है। बहुत आनंददायक टिप्पणियों और आपके उत्तर के लिए धन्यवाद।

— वादिम समोखिन

Answer 2

जैसा कि अन्य कह रहे हैं, आदर्श रूप से श्रमिक आय वर्ग निरंतरता के मानकीकरण की अनुमति देगा, जिससे यह वर्ग उस मूल्य से स्वतंत्र हो जाएगा।

अंततः, कॉलिंग एप्लिकेशन बाहरी कॉन्फ़िगरेशन (उदाहरण के लिए एक फ़ाइल) के संदर्भ में पैरामीटर के लिए भी अनुमति दे सकता है। एक बार जब हमारे पास बाहरी कॉन्फ़िगरेशन हो जाता है, तो हम कर की दर बदल सकते हैं - हालांकि विचार करें कि यदि कॉन्फ़िगरेशन फ़ाइल को स्टार्टअप पर केवल एक बार पढ़ा जाता है, तो प्रभावी होने के लिए अद्यतन कर प्रतिशत के लिए आवेदन को फिर से शुरू करना होगा, ताकि कुछ रखने के लिए है मन। ऐसा करने के लिए निर्देशित करने पर हम कॉन्फ़िगरेशन को फिर से शुरू करने के लिए एक एप्लिकेशन सुविधा प्रदान कर सकते हैं, या हम एक अधिक जटिल तंत्र प्रदान कर सकते हैं जो कॉन्फ़िगरेशन फ़ाइल में परिवर्तन होने पर नोटिस करता है ...

दीर्घकालिक, आप पा सकते हैं कि कर के मुद्दों को केवल एक प्रतिशत से अधिक की आवश्यकता है - उदाहरण के लिए, कि एक दिन कर कानून अधिक जटिल हैं और कई प्रतिशत और कुछ स्थिरांक की आवश्यकता होती है (उदाहरण के लिए $ 10k के तहत राशि पर X% कर लगाया गया, जबकि शेष Y% पर कर लगाया गया)।

यह मूल रूप से एक रणनीति पैटर्न का उपयोग करने का सुझाव देता है, जहां प्रश्न में मुख्य वर्ग कर की गणना के लिए एक रणनीति वस्तु को स्वीकार करता है।

विभिन्न रणनीतियों (और% और $ स्थिरांक) को विन्यास फाइल से चुनने में सक्षम होना चाहिए, और अब, एक नई रणनीति को जोड़ने के लिए कुछ नए कोड जोड़ने की आवश्यकता होती है, लेकिन जरूरी नहीं कि मौजूदा कोड में अपडेट हो।

प्रत्येक रणनीति यह जान सकती है कि वास्तविक टैक्स की गणना करने के साथ-साथ अपने स्वयं के बाहरी कॉन्फ़िगरेशन तर्कों को कैसे पार्स / व्याख्या करें।

डायनामिक रूप से, टैक्स आगे चलकर शासी लोकल पर निर्भर हो सकता है, इसलिए आपके पास कमाई या कर्मचारियों (या दोनों) के साथ जुड़ा हुआ लोकल हो सकता है। बाहरी कॉन्फ़िगरेशन में, हम लोकेल को कर रणनीति के साथ जोड़ सकते हैं।

---

निर्भरता इंजेक्शन भी देखें , जहां हम इन चीजों का प्रबंधन करते हैं।

Comments

प्रश्न यह नहीं था कि क्या कोड में कर प्रतिशत की तरह किसी चीज़ को दफनाने के लिए एक बुरा विचार है, मुझे यकीन है कि यहाँ (ओपी सहित) हम में से अधिकांश के लिए स्पष्ट है। सवाल था, "क्या यह OCP का उल्लंघन करता है?" इसलिए मैं नहीं देखता कि आपका उत्तर इस प्रश्न को कैसे संदर्भित करता है।

— Doc Brown

Answer 3

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

यदि आपकी कक्षा को अर्थ दिया जाता है (जिसका अर्थ है कि यह एक स्थिर वर्ग नहीं है), कर चर वर्ग की संपत्ति बनाकर, जिसका मूल्य कंस्ट्रक्टर के माध्यम से इंजेक्ट किया जाता है, तो आप वर्ग सामंजस्य में भी सुधार करेंगे।

संक्षेप में, आपका वर्तमान डिज़ाइन आपकी कक्षा को एक निरंतर मूल्य पर निर्भर करता है जो वास्तव में एक स्थिरांक नहीं है (मान के रूप में स्थिर को परिभाषित करता है जो कभी भी पीआई के मूल्य की तरह कोई भी परिवर्तन नहीं करेगा)। यह OCP का उल्लंघन करता है। निर्माता तर्क के रूप में कर मूल्य प्राप्त करने के लिए डिज़ाइन बदलें।

Answer 4

पूरी तरह से @Becuzz से सहमत हैं, और मैं बस इसे संक्षेप में प्रस्तुत करना चाहता हूं: OCP पुन: उपयोग किए गए (इसलिए, उपयोगी) सार को खोजने के बारे में है जो एक कक्षा में इंजेक्ट किया जाता है। इसलिए कक्षा का व्यवहार उसके कोड को बदलकर नहीं, बल्कि उसे अलग-अलग कार्यान्वयन के साथ प्रदान करके संशोधित किया जाता है। यह रॉबर्ट मार्टिन की पुस्तक " एजाइल सॉफ्टवेयर डेवलपमेंट, प्रिंसिपल्स, पैटर्न, एंड प्रैक्टिस " में स्पष्ट किया गया है , इसी अध्याय "द ओपन-क्लोज्ड सिद्धांत", "एब्स्ट्रेक्शन इज की" उप-अध्याय की जाँच करें। यह एक और गलतफहमी को स्पष्ट करता है कि व्यवहार को केवल विरासत के साथ संशोधित किया जा सकता है। यह बर्ट्रेंड मेयर था जिसने 1988 में अपनी पुस्तक " ऑब्जेक्ट ओरिएंटेड सॉफ्टवेयर कंस्ट्रक्शन " में प्रस्तावित किया था , रॉबर्ट मार्टिन ने नहीं।

Answer 5

जिस तरह से मैं इसे देखता हूं वह खुले बंद सिद्धांत का उल्लंघन नहीं है। फिर भी, तथ्य यह है कि कुछ है जो समय में परिवर्तन के लिए बाध्य है (जैसे कर प्रतिशत) एक निरंतरता एक डिजाइन दोष है: आपको निरंतरता के मूल्य को नहीं बदलना चाहिए लेकिन आप कर प्रतिशत को कैसे संभालते हैं। यह किसी प्रकार की सेटिंग होनी चाहिए जिसे पूरी तरह से पुनः स्थापित किए बिना संशोधित किया जा सके।

Comments

"डिज़ाइन दोष" होने के कारण यह खुले बंद सिद्धांत का उल्लंघन कर रहा है क्योंकि आपको निरंतर बदलने के लिए कोड को फिर से स्थापित करने की आवश्यकता है?

— एडरिक आयरनरोज़