नाजुक आधार वर्ग: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(4 intermediate revisions by 4 users not shown)
Line 1: Line 1:
''यह लेख स्थापत्य दोष से सम्बंधित है। भाषा कार्यान्वयन समस्या के लिए दुर्बल बाइनरी इंटरफेस समस्या देखें।''{{Short description|Object-oriented programming system problem}}
'''''फ़्रैजाइल्‌ बेस क्लास''''' की समस्या वस्तु-उन्मुख प्रोग्राम प्रणाली की एक मूलभूत स्थापत्य समस्या है जहां बेस क्लास ([[सुपरक्लास (कंप्यूटर विज्ञान)]]) को फ़्रैजाइल्‌ माना जाता है क्योंकि [[उपवर्ग (कंप्यूटर विज्ञान)|उप-क्लास (कंप्यूटर विज्ञान)]] द्वारा इनहेरिटेंस होने पर बेस क्लास के लिए सुरक्षित रूप से सुरक्षित संशोधन, व्युत्पन्न कक्षाएँ को अपक्रिया का कारण बन सकता है। प्रोग्रामर यह निर्धारित नहीं कर सकता है कि बेस क्लास के तरीकों को वियोजन में जांच कर बेस क्लास परिवर्तन सुरक्षित है या नहीं।
'''''दुर्बल आधार कक्षा''''' की समस्या वस्तु-उन्मुख प्रोग्राम प्रणाली की एक मूलभूत स्थापत्य समस्या है जहां आधार कक्षा ([[सुपरक्लास (कंप्यूटर विज्ञान)]]) को दुर्बल माना जाता है क्योंकि [[उपवर्ग (कंप्यूटर विज्ञान)|उप-कक्षा (कंप्यूटर विज्ञान)]] द्वारा इनहेरिटेंस होने पर आधार कक्षा के लिए सुरक्षित रूप से सुरक्षित संशोधन, व्युत्पन्न कक्षाएँ को अपक्रिया का कारण बन सकता है। प्रोग्रामर यह निर्धारित नहीं कर सकता है कि आधार कक्षा के तरीकों को वियोजन में जांच कर आधार कक्षा परिवर्तन सुरक्षित है या नहीं।


एक संभावित समाधान उदाहरण चर को उनके परिभाषित कक्षा के लिए वैयक्तिक बनाना है और उपवर्गों को सुपरक्लास स्थितियों को संशोधित करने के लिए निर्धारक का उपयोग करने के लिए प्रभावित करना है। और एक भाषा भी इसे बना सकती है ताकि उप- कक्षा नियंत्रित कर सकें कि कौन सी इनहेरिटेंस विधियों को सार्वजनिक रूप से प्रदर्शित किया गया है। ये परिवर्तन उपवर्गों को सुपरक्लास के कार्यान्वयन विवरण पर निर्भर करने से रोकते हैं और उपवर्गों को केवल उन्हीं सुपरक्लास विधियों को प्रदर्शित करने की स्वीकृति देते हैं जो स्वयं पर प्रयुक्त होती हैं।
एक संभावित समाधान उदाहरण चर को उनके परिभाषित क्लास के लिए वैयक्तिक बनाना है और उपवर्गों को सुपरक्लास स्थितियों को संशोधित करने के लिए निर्धारक का उपयोग करने के लिए प्रभावित करना है। और एक भाषा भी इसे बना सकती है ताकि सबक्लास नियंत्रित कर सकें कि कौन सी इनहेरिटेंस विधियों को सार्वजनिक रूप से प्रदर्शित किया गया है। ये परिवर्तन उपवर्गों को सुपरक्लास के कार्यान्वयन विवरण पर निर्भर करने से रोकते हैं और उपवर्गों को केवल उन्हीं सुपरक्लास विधियों को प्रदर्शित करने की स्वीकृति देते हैं जो स्वयं पर प्रयुक्त होती हैं।


सुपरक्लास के अतिरिक्त अन्य वैकल्पिक समाधान एक इंटरफेस ([[ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग|वस्तु-उन्मुख प्रोग्राम]]) हो सकता है।
सुपरक्लास के अतिरिक्त अन्य वैकल्पिक समाधान एक इंटरफेस ([[ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग|वस्तु-उन्मुख प्रोग्राम]]) हो सकता है।


दुर्बल आधार कक्षा की समस्या को खुले पुनरावर्तन (पर विधियों के गतिशील प्रेषण) पर दोष दिया गया है), इस सुझाव के साथ कि खुले पुनरावर्तन (गतिशील प्रेषण, देर से बाध्यकारी) के अतिरिक्त इस डिफ़ॉल्ट पर बंद पुनरावर्तन (स्थैतिक प्रेषण, प्रारंभिक बाध्यकारी) पर विधियों का निर्देशित किया गया है। केवल खुले पुनरावर्तन का उपयोग करते हुए जब इसे विशेष रूप से बाह्य निर्देश का अनुरोध किया जाता है (इसका उपयोग नहीं किया जाता है) सामान्य रूप से गतिशील रूप से प्रेषित किया जाएगा।<ref>"[https://www.cs.cmu.edu/~aldrich/papers/selective-open-recursion.pdf Selective Open Recursion: A Solution to the Fragile Base Class Problem]", Jonathan Aldrich</ref><ref>"[http://lambda-the-ultimate.org/classic/message12271.html Selective Open Recursion: A Solution to the Fragile Base Class Problem]", ''[http://lambda-the-ultimate.org/ Lambda the Ultimate]''</ref>
फ़्रैजाइल्‌ बेस क्लास की समस्या को खुले पुनरावर्तन (पर विधियों के गतिशील प्रेषण) पर दोष दिया गया है), इस सुझाव के साथ कि खुले पुनरावर्तन (गतिशील प्रेषण, देर से बाध्यकारी) के अतिरिक्त इस डिफ़ॉल्ट पर बंद पुनरावर्तन (स्थैतिक प्रेषण, प्रारंभिक बाध्यकारी) पर विधियों का कॉल किया गया है। केवल खुले पुनरावर्तन का उपयोग करते हुए जब इसे विशेष रूप से बाह्य कॉल का अनुरोध किया जाता है (इसका उपयोग नहीं किया जाता है) सामान्य रूप से गतिशील रूप से प्रेषित किया जाएगा।<ref>"[https://www.cs.cmu.edu/~aldrich/papers/selective-open-recursion.pdf Selective Open Recursion: A Solution to the Fragile Base Class Problem]", Jonathan Aldrich</ref><ref>"[http://lambda-the-ultimate.org/classic/message12271.html Selective Open Recursion: A Solution to the Fragile Base Class Problem]", ''[http://lambda-the-ultimate.org/ Lambda the Ultimate]''</ref>




== जावा उदाहरण ==
== जावा उदाहरण ==
निम्नलिखित साधारण उदाहरण [[जावा प्रोग्रामिंग भाषा|जावा प्रोग्राम भाषा]] में लिखा गया है और दिखाता है कि कैसे एक आधार कक्षा का प्रतीत होता है कि सुरक्षित संशोधन एक इनहेरिटेंस उप- कक्षा को अनंत पुनरावर्तन में प्रवेश करके अपक्रिया का कारण बन सकता है जिसके परिणामस्वरूप संग्रह की अधिकता होगी।
निम्नलिखित साधारण उदाहरण [[जावा प्रोग्रामिंग भाषा|जावा प्रोग्राम भाषा]] में लिखा गया है और दिखाता है कि कैसे एक बेस क्लास का प्रतीत होता है कि सुरक्षित संशोधन एक इनहेरिटेंस सबक्लास को अनंत पुनरावर्तन में प्रवेश करके अपक्रिया का कारण बन सकता है जिसके परिणामस्वरूप संग्रह की अधिकता होगी।
  class Super {
  class Super {
   
   
Line 34: Line 33:
  }
  }


उप के एक उदाहरण पर गतिशील रूप से बाध्य विधि inc2() को निर्देशित करने से क्षेत्र काउंटर को एक से सही रूप से बढ़ाया जाएगा। यदि हालांकि सुपरक्लास का कोड निम्नलिखित तरीके से परिवर्तित कर दिया गया है:
उप के एक उदाहरण पर गतिशील रूप से बाध्य विधि inc2() को कॉल करने से क्षेत्र काउंटर को एक से सही रूप से बढ़ाया जाएगा। यदि हालांकि सुपरक्लास का कोड निम्नलिखित तरीके से परिवर्तित कर दिया गया है:
  class Super {
  class Super {
   
   
Line 48: Line 47:
  }
  }


उप के एक उदाहरण पर गतिशील रूप से बाध्य विधि inc2() को निर्देशित करने से सुपरक्लास के स्वयं और विधि inc1() के बीच एक [[अनंत पुनरावर्तन]] होगा और अंत में [[स्टैक ओवरफ़्लो|संग्रह की अधिकता]] हो जाएगी। सुपरक्लास में विधियों को 'अंतिम' घोषित करके इस समस्या से बचा जा सकता था, जिससे उप- कक्षा के लिए उन्हें स्वचालित प्रक्रिया को रद्द करना असंभव हो जाता है। हालांकि, यह सदैव वांछनीय या संभव नहीं होता है। इसलिए, सुपरक्लास के लिए गतिशील-परिबद्ध विधियों में निर्देश परिवर्तित करने से बचना अच्छा अभ्यास है।
उप के एक उदाहरण पर गतिशील रूप से बाध्य विधि inc2() को कॉल करने से सुपरक्लास के स्वयं और विधि inc1() के बीच एक [[अनंत पुनरावर्तन]] होगा और अंत में [[स्टैक ओवरफ़्लो|संग्रह की अधिकता]] हो जाएगी। सुपरक्लास में विधियों को 'अंतिम' घोषित करके इस समस्या से बचा जा सकता था, जिससे सबक्लास के लिए उन्हें स्वचालित प्रक्रिया को रद्द करना असंभव हो जाता है। हालांकि, यह सदैव वांछनीय या संभव नहीं होता है। इसलिए, सुपरक्लास के लिए गतिशील-परिबद्ध विधियों में कॉल परिवर्तित करने से बचना अच्छा अभ्यास है।


== समाधान ==
== समाधान ==
* [[उद्देश्य सी|उद्देश्य-C]] में श्रेणियां और साथ ही गैर-दुर्बल उदाहरण चर हैं।
* [[उद्देश्य सी|उद्देश्य-C]] में श्रेणियां और साथ ही गैर-फ़्रैजाइल्‌ उदाहरण चर हैं।
* [[घटक पास्कल]] सुपरक्लास (कंप्यूटर विज्ञान) को बहिष्कृत करता है।
* [[घटक पास्कल]] सुपरक्लास (कंप्यूटर विज्ञान) को बहिष्कृत करता है।
* जावा, C++ (C++11 के बाद से) और D "अंतिम" कीवर्ड के साथ क्रमशः कक्षा या विधि की घोषणा को लेबल करके इनहेरिटेंस (वंशानुक्रम) या कक्षा विधि को ओवरराइड करने की स्वीकृति देते हैं। प्रभावी जावा पुस्तक में, लेखक जोशुआ ब्लोच लिखते हैं (वस्तु 17 में) कि प्रोग्रामर को "इनहेरिटेंस के लिए डिजाइन और दस्तावेज या अन्यथा इसे प्रतिबंधित करना चाहिए"।
* जावा, C++ (C++11 के बाद से) और D "अंतिम" कीवर्ड के साथ क्रमशः क्लास या विधि की घोषणा को लेबल करके इनहेरिटेंस (वंशानुक्रम) या क्लास विधि को ओवरराइड करने की स्वीकृति देते हैं। प्रभावी जावा पुस्तक में, लेखक जोशुआ ब्लोच लिखते हैं (वस्तु 17 में) कि प्रोग्रामर को "इनहेरिटेंस के लिए डिजाइन और दस्तावेज या अन्यथा इसे प्रतिबंधित करना चाहिए"।
* जावा की तरह C# और VB.NET में इनहेरिटेंस को प्रतिबंधित करने के लिए "मुद्रांकित" और "इनहेरिटेबल नहीं" कक्षा प्रकाशन कीवर्ड हैं, और ओवरराइड विधियों पर कीवर्ड "अधिभूत" का उपयोग करने के लिए उप-कक्षा की आवश्यकता होती है, वही समाधान बाद में स्काला द्वारा स्वीकृत किया गया।<ref>{{Cite web | url=https://msdn.microsoft.com/en-us/library/ebca9ah3.aspx | title=Override modifier - C# Reference }}</ref>  
* जावा की तरह C# और VB.NET में इनहेरिटेंस को प्रतिबंधित करने के लिए "मुद्रांकित" और "इनहेरिटेबल नहीं" क्लास प्रकाशन कीवर्ड हैं, और ओवरराइड विधियों पर कीवर्ड "ओवरराइड" का उपयोग करने के लिए उप-क्लास की आवश्यकता होती है, वही समाधान बाद में स्काला द्वारा स्वीकृत किया गया।<ref>{{Cite web | url=https://msdn.microsoft.com/en-us/library/ebca9ah3.aspx | title=Override modifier - C# Reference }}</ref>  
* स्काला को मूल कक्षा विधि को ओवरराइड करने के लिए स्पष्ट रूप से कीवर्ड "ओवरराइड" का उपयोग करने के लिए एक उप-कक्षा की आवश्यकता होती है। "प्रोग्रामिंग इन स्काला, द्वितीय संस्करण" पुस्तक में, लेखक लिखता है कि (यहां संशोधनों के साथ) यदि कोई विधि f() नहीं थी, तो क्लाइंट के विधि f() के मूल कार्यान्वयन में ओवरराइड संशोधक नहीं हो सकता था। एक बार जब आप अपने पुस्तकालय कक्षा के दूसरे संस्करण में f() विधि जोड़ते हैं, तो क्लाइंट कोड का पुन: संकलन गलत गतिविधि के अतिरिक्त संकलन त्रुटि देगा।
* स्काला को पैरेंट क्लास विधि को ओवरराइड करने के लिए स्पष्ट रूप से कीवर्ड "ओवरराइड" का उपयोग करने के लिए एक उप-क्लास की आवश्यकता होती है। "प्रोग्रामिंग इन स्काला, द्वितीय संस्करण" पुस्तक में, लेखक लिखता है कि (यहां संशोधनों के साथ) यदि कोई विधि f() नहीं थी, तो क्लाइंट के विधि f() के मूल कार्यान्वयन में ओवरराइड संशोधक नहीं हो सकता था। एक बार जब आप अपने पुस्तकालय क्लास के दूसरे संस्करण में f() विधि जोड़ते हैं, तो क्लाइंट कोड का पुन: संकलन गलत गतिविधि के अतिरिक्त संकलन त्रुटि देगा।
* कोटलिन में कक्षाएं और विधियां डिफ़ॉल्ट रूप से अंतिम होती हैं। कक्षा वंशानुक्रम को सक्षम करने के लिए, कक्षा को खुले संशोधक के साथ चिह्नित किया जाना चाहिए। इसी तरह, विधि को ओवरराइड करने की स्वीकृति देने के लिए एक विधि को खुले के रूप में चिह्नित किया जाना चाहिए।
* कोटलिन में कक्षाएं और विधियां डिफ़ॉल्ट रूप से अंतिम होती हैं। क्लास वंशानुक्रम को सक्षम करने के लिए, क्लास को खुले संशोधक के साथ चिह्नित किया जाना चाहिए। इसी तरह, विधि को ओवरराइड करने की स्वीकृति देने के लिए एक विधि को ओपन के रूप में चिह्नित किया जाना चाहिए।
* जूलिया (प्रोग्राम भाषा) अमूर्त प्रकारों के केवल उप-प्रकार की स्वीकृति देता है और [[वंशानुक्रम (वस्तु-उन्मुख प्रोग्रामिंग)|इनहेरिटेंस (वस्तु-उन्मुख प्रोग्राम)]] के विकल्प के रूप में रचना का उपयोग करता है। हालाँकि इसमें कई प्रेषण हैं।
* जूलिया (प्रोग्राम भाषा) अमूर्त प्रकारों के केवल उप-प्रकार की स्वीकृति देता है और [[वंशानुक्रम (वस्तु-उन्मुख प्रोग्रामिंग)|इनहेरिटेंस (वस्तु-उन्मुख प्रोग्राम)]] के विकल्प के रूप में रचना का उपयोग करता है। हालाँकि इसमें कई प्रेषण हैं।


== यह भी देखें ==
== यह भी देखें ==
* [[नाजुक बाइनरी इंटरफ़ेस समस्या|दुर्बल बाइनरी इंटरफेस समस्या]]
* [[नाजुक बाइनरी इंटरफ़ेस समस्या|फ़्रैजाइल्‌ बाइनरी इंटरफेस समस्या]]
* [[कार्यान्वयन विरासत|कार्यान्वयन इनहेरिटेंस]]
* [[कार्यान्वयन विरासत|कार्यान्वयन इनहेरिटेंस]]
* [[वंशानुक्रम शब्दार्थ|इनहेरिटेंस शब्दार्थ]]
* [[वंशानुक्रम शब्दार्थ|इनहेरिटेंस शब्दार्थ]]
Line 74: Line 73:
* {{cite web |last1=Holub |first1=Allen |date=2003-08-01 |df=mdy |url=https://www.infoworld.com/article/2073649/why-extends-is-evil.html |title=Why extends is evil |department=Java Toolbox |work=[[JavaWorld]] |access-date=2020-07-21}}
* {{cite web |last1=Holub |first1=Allen |date=2003-08-01 |df=mdy |url=https://www.infoworld.com/article/2073649/why-extends-is-evil.html |title=Why extends is evil |department=Java Toolbox |work=[[JavaWorld]] |access-date=2020-07-21}}


{{DEFAULTSORT:Fragile Base Class}}[[Category: वर्ग (कंप्यूटर प्रोग्रामिंग)]]
{{DEFAULTSORT:Fragile Base Class}}


 
[[Category:Created On 16/02/2023|Fragile Base Class]]
 
[[Category:Machine Translated Page|Fragile Base Class]]
[[Category: Machine Translated Page]]
[[Category:Pages with script errors|Fragile Base Class]]
[[Category:Created On 16/02/2023]]
[[Category:Templates Vigyan Ready|Fragile Base Class]]
[[Category:वर्ग (कंप्यूटर प्रोग्रामिंग)|Fragile Base Class]]

Latest revision as of 20:38, 20 February 2023

फ़्रैजाइल्‌ बेस क्लास की समस्या वस्तु-उन्मुख प्रोग्राम प्रणाली की एक मूलभूत स्थापत्य समस्या है जहां बेस क्लास (सुपरक्लास (कंप्यूटर विज्ञान)) को फ़्रैजाइल्‌ माना जाता है क्योंकि उप-क्लास (कंप्यूटर विज्ञान) द्वारा इनहेरिटेंस होने पर बेस क्लास के लिए सुरक्षित रूप से सुरक्षित संशोधन, व्युत्पन्न कक्षाएँ को अपक्रिया का कारण बन सकता है। प्रोग्रामर यह निर्धारित नहीं कर सकता है कि बेस क्लास के तरीकों को वियोजन में जांच कर बेस क्लास परिवर्तन सुरक्षित है या नहीं।

एक संभावित समाधान उदाहरण चर को उनके परिभाषित क्लास के लिए वैयक्तिक बनाना है और उपवर्गों को सुपरक्लास स्थितियों को संशोधित करने के लिए निर्धारक का उपयोग करने के लिए प्रभावित करना है। और एक भाषा भी इसे बना सकती है ताकि सबक्लास नियंत्रित कर सकें कि कौन सी इनहेरिटेंस विधियों को सार्वजनिक रूप से प्रदर्शित किया गया है। ये परिवर्तन उपवर्गों को सुपरक्लास के कार्यान्वयन विवरण पर निर्भर करने से रोकते हैं और उपवर्गों को केवल उन्हीं सुपरक्लास विधियों को प्रदर्शित करने की स्वीकृति देते हैं जो स्वयं पर प्रयुक्त होती हैं।

सुपरक्लास के अतिरिक्त अन्य वैकल्पिक समाधान एक इंटरफेस (वस्तु-उन्मुख प्रोग्राम) हो सकता है।

फ़्रैजाइल्‌ बेस क्लास की समस्या को खुले पुनरावर्तन (पर विधियों के गतिशील प्रेषण) पर दोष दिया गया है), इस सुझाव के साथ कि खुले पुनरावर्तन (गतिशील प्रेषण, देर से बाध्यकारी) के अतिरिक्त इस डिफ़ॉल्ट पर बंद पुनरावर्तन (स्थैतिक प्रेषण, प्रारंभिक बाध्यकारी) पर विधियों का कॉल किया गया है। केवल खुले पुनरावर्तन का उपयोग करते हुए जब इसे विशेष रूप से बाह्य कॉल का अनुरोध किया जाता है (इसका उपयोग नहीं किया जाता है) सामान्य रूप से गतिशील रूप से प्रेषित किया जाएगा।[1][2]


जावा उदाहरण

निम्नलिखित साधारण उदाहरण जावा प्रोग्राम भाषा में लिखा गया है और दिखाता है कि कैसे एक बेस क्लास का प्रतीत होता है कि सुरक्षित संशोधन एक इनहेरिटेंस सबक्लास को अनंत पुनरावर्तन में प्रवेश करके अपक्रिया का कारण बन सकता है जिसके परिणामस्वरूप संग्रह की अधिकता होगी। 

class Super {

 private int counter = 0;

 void inc1() {
    counter++;
 }

 void inc2() {
    counter++;
 }

}

class Sub extends Super {

 @Override
 void inc2() {
    inc1();
 }

}

उप के एक उदाहरण पर गतिशील रूप से बाध्य विधि inc2() को कॉल करने से क्षेत्र काउंटर को एक से सही रूप से बढ़ाया जाएगा। यदि हालांकि सुपरक्लास का कोड निम्नलिखित तरीके से परिवर्तित कर दिया गया है: 

class Super {

 private int counter = 0;

 void inc1() {
    inc2();
 }

 void inc2() {
    counter++;
 }
}

उप के एक उदाहरण पर गतिशील रूप से बाध्य विधि inc2() को कॉल करने से सुपरक्लास के स्वयं और विधि inc1() के बीच एक अनंत पुनरावर्तन होगा और अंत में संग्रह की अधिकता हो जाएगी। सुपरक्लास में विधियों को 'अंतिम' घोषित करके इस समस्या से बचा जा सकता था, जिससे सबक्लास के लिए उन्हें स्वचालित प्रक्रिया को रद्द करना असंभव हो जाता है। हालांकि, यह सदैव वांछनीय या संभव नहीं होता है। इसलिए, सुपरक्लास के लिए गतिशील-परिबद्ध विधियों में कॉल परिवर्तित करने से बचना अच्छा अभ्यास है।

समाधान

  • उद्देश्य-C में श्रेणियां और साथ ही गैर-फ़्रैजाइल्‌ उदाहरण चर हैं।
  • घटक पास्कल सुपरक्लास (कंप्यूटर विज्ञान) को बहिष्कृत करता है।
  • जावा, C++ (C++11 के बाद से) और D "अंतिम" कीवर्ड के साथ क्रमशः क्लास या विधि की घोषणा को लेबल करके इनहेरिटेंस (वंशानुक्रम) या क्लास विधि को ओवरराइड करने की स्वीकृति देते हैं। प्रभावी जावा पुस्तक में, लेखक जोशुआ ब्लोच लिखते हैं (वस्तु 17 में) कि प्रोग्रामर को "इनहेरिटेंस के लिए डिजाइन और दस्तावेज या अन्यथा इसे प्रतिबंधित करना चाहिए"।
  • जावा की तरह C# और VB.NET में इनहेरिटेंस को प्रतिबंधित करने के लिए "मुद्रांकित" और "इनहेरिटेबल नहीं" क्लास प्रकाशन कीवर्ड हैं, और ओवरराइड विधियों पर कीवर्ड "ओवरराइड" का उपयोग करने के लिए उप-क्लास की आवश्यकता होती है, वही समाधान बाद में स्काला द्वारा स्वीकृत किया गया।[3]
  • स्काला को पैरेंट क्लास विधि को ओवरराइड करने के लिए स्पष्ट रूप से कीवर्ड "ओवरराइड" का उपयोग करने के लिए एक उप-क्लास की आवश्यकता होती है। "प्रोग्रामिंग इन स्काला, द्वितीय संस्करण" पुस्तक में, लेखक लिखता है कि (यहां संशोधनों के साथ) यदि कोई विधि f() नहीं थी, तो क्लाइंट के विधि f() के मूल कार्यान्वयन में ओवरराइड संशोधक नहीं हो सकता था। एक बार जब आप अपने पुस्तकालय क्लास के दूसरे संस्करण में f() विधि जोड़ते हैं, तो क्लाइंट कोड का पुन: संकलन गलत गतिविधि के अतिरिक्त संकलन त्रुटि देगा।
  • कोटलिन में कक्षाएं और विधियां डिफ़ॉल्ट रूप से अंतिम होती हैं। क्लास वंशानुक्रम को सक्षम करने के लिए, क्लास को खुले संशोधक के साथ चिह्नित किया जाना चाहिए। इसी तरह, विधि को ओवरराइड करने की स्वीकृति देने के लिए एक विधि को ओपन के रूप में चिह्नित किया जाना चाहिए।
  • जूलिया (प्रोग्राम भाषा) अमूर्त प्रकारों के केवल उप-प्रकार की स्वीकृति देता है और इनहेरिटेंस (वस्तु-उन्मुख प्रोग्राम) के विकल्प के रूप में रचना का उपयोग करता है। हालाँकि इसमें कई प्रेषण हैं।

यह भी देखें

संदर्भ

  1. ↑ "Selective Open Recursion: A Solution to the Fragile Base Class Problem", Jonathan Aldrich
  2. ↑ "Selective Open Recursion: A Solution to the Fragile Base Class Problem", Lambda the Ultimate
  3. ↑ "Override modifier - C# Reference".


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=नाजुक_आधार_वर्ग&oldid=92585’