नाजुक आधार वर्ग: Difference between revisions
From Vigyanwiki
(Created page with "{{Short description|Object-oriented programming system problem}} {{About|the architectural problem|the language implementation problem|Fragile binary interface problem}} {{Mor...") |
No edit summary |
||
| (6 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
'''''फ़्रैजाइल् बेस क्लास''''' की समस्या वस्तु-उन्मुख प्रोग्राम प्रणाली की एक मूलभूत स्थापत्य समस्या है जहां बेस क्लास ([[सुपरक्लास (कंप्यूटर विज्ञान)]]) को फ़्रैजाइल् माना जाता है क्योंकि [[उपवर्ग (कंप्यूटर विज्ञान)|उप-क्लास (कंप्यूटर विज्ञान)]] द्वारा इनहेरिटेंस होने पर बेस क्लास के लिए सुरक्षित रूप से सुरक्षित संशोधन, व्युत्पन्न कक्षाएँ को अपक्रिया का कारण बन सकता है। प्रोग्रामर यह निर्धारित नहीं कर सकता है कि बेस क्लास के तरीकों को वियोजन में जांच कर बेस क्लास परिवर्तन सुरक्षित है या नहीं। | |||
एक संभावित समाधान उदाहरण चर को उनके परिभाषित | एक संभावित समाधान उदाहरण चर को उनके परिभाषित क्लास के लिए वैयक्तिक बनाना है और उपवर्गों को सुपरक्लास स्थितियों को संशोधित करने के लिए निर्धारक का उपयोग करने के लिए प्रभावित करना है। और एक भाषा भी इसे बना सकती है ताकि सबक्लास नियंत्रित कर सकें कि कौन सी इनहेरिटेंस विधियों को सार्वजनिक रूप से प्रदर्शित किया गया है। ये परिवर्तन उपवर्गों को सुपरक्लास के कार्यान्वयन विवरण पर निर्भर करने से रोकते हैं और उपवर्गों को केवल उन्हीं सुपरक्लास विधियों को प्रदर्शित करने की स्वीकृति देते हैं जो स्वयं पर प्रयुक्त होती हैं। | ||
सुपरक्लास के | सुपरक्लास के अतिरिक्त अन्य वैकल्पिक समाधान एक इंटरफेस ([[ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग|वस्तु-उन्मुख प्रोग्राम]]) हो सकता है। | ||
फ़्रैजाइल् बेस क्लास की समस्या को खुले पुनरावर्तन (पर विधियों के गतिशील प्रेषण) पर दोष दिया गया है), इस सुझाव के साथ कि खुले पुनरावर्तन (गतिशील प्रेषण, देर से बाध्यकारी) के अतिरिक्त इस डिफ़ॉल्ट पर बंद पुनरावर्तन (स्थैतिक प्रेषण, प्रारंभिक बाध्यकारी) पर विधियों का कॉल किया गया है। केवल खुले पुनरावर्तन का उपयोग करते हुए जब इसे विशेष रूप से बाह्य कॉल का अनुरोध किया जाता है (इसका उपयोग नहीं किया जाता है) सामान्य रूप से गतिशील रूप से प्रेषित किया जाएगा।<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 { | |||
private int counter = 0; | |||
void inc1() { | |||
counter++; | |||
} | } | ||
void inc2() { | |||
counter++; | |||
} | } | ||
} | } | ||
class Sub extends Super { | |||
@Override | @Override | ||
void inc2() { | |||
inc1(); | |||
} | } | ||
} | |||
उप के एक उदाहरण पर गतिशील रूप से बाध्य विधि inc2() को कॉल करने से क्षेत्र काउंटर को एक से सही रूप से बढ़ाया जाएगा। यदि हालांकि सुपरक्लास का कोड निम्नलिखित तरीके से परिवर्तित कर दिया गया है: | |||
class Super { | |||
उप के एक उदाहरण पर गतिशील रूप से बाध्य विधि inc2() को कॉल करने से | private int counter = 0; | ||
void inc1() { | |||
inc2(); | |||
} | } | ||
void inc2() { | |||
counter++; | |||
} | } | ||
} | } | ||
उप के एक उदाहरण पर गतिशील रूप से बाध्य विधि inc2() को कॉल करने से | उप के एक उदाहरण पर गतिशील रूप से बाध्य विधि inc2() को कॉल करने से सुपरक्लास के स्वयं और विधि inc1() के बीच एक [[अनंत पुनरावर्तन]] होगा और अंत में [[स्टैक ओवरफ़्लो|संग्रह की अधिकता]] हो जाएगी। सुपरक्लास में विधियों को 'अंतिम' घोषित करके इस समस्या से बचा जा सकता था, जिससे सबक्लास के लिए उन्हें स्वचालित प्रक्रिया को रद्द करना असंभव हो जाता है। हालांकि, यह सदैव वांछनीय या संभव नहीं होता है। इसलिए, सुपरक्लास के लिए गतिशील-परिबद्ध विधियों में कॉल परिवर्तित करने से बचना अच्छा अभ्यास है। | ||
== समाधान == | == समाधान == | ||
* [[उद्देश्य सी]] में | * [[उद्देश्य सी|उद्देश्य-C]] में श्रेणियां और साथ ही गैर-फ़्रैजाइल् उदाहरण चर हैं। | ||
* [[घटक पास्कल]] सुपरक्लास (कंप्यूटर विज्ञान) को बहिष्कृत करता है। | * [[घटक पास्कल]] सुपरक्लास (कंप्यूटर विज्ञान) को बहिष्कृत करता है। | ||
* | * जावा, 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> | ||
* | * स्काला को पैरेंट क्लास विधि को ओवरराइड करने के लिए स्पष्ट रूप से कीवर्ड "ओवरराइड" का उपयोग करने के लिए एक उप-क्लास की आवश्यकता होती है। "प्रोग्रामिंग इन स्काला, द्वितीय संस्करण" पुस्तक में, लेखक लिखता है कि (यहां संशोधनों के साथ) यदि कोई विधि f() नहीं थी, तो क्लाइंट के विधि f() के मूल कार्यान्वयन में ओवरराइड संशोधक नहीं हो सकता था। एक बार जब आप अपने पुस्तकालय क्लास के दूसरे संस्करण में f() विधि जोड़ते हैं, तो क्लाइंट कोड का पुन: संकलन गलत गतिविधि के अतिरिक्त संकलन त्रुटि देगा। | ||
* | * कोटलिन में कक्षाएं और विधियां डिफ़ॉल्ट रूप से अंतिम होती हैं। क्लास वंशानुक्रम को सक्षम करने के लिए, क्लास को खुले संशोधक के साथ चिह्नित किया जाना चाहिए। इसी तरह, विधि को ओवरराइड करने की स्वीकृति देने के लिए एक विधि को ओपन के रूप में चिह्नित किया जाना चाहिए। | ||
* जूलिया ( | * जूलिया (प्रोग्राम भाषा) अमूर्त प्रकारों के केवल उप-प्रकार की स्वीकृति देता है और [[वंशानुक्रम (वस्तु-उन्मुख प्रोग्रामिंग)|इनहेरिटेंस (वस्तु-उन्मुख प्रोग्राम)]] के विकल्प के रूप में रचना का उपयोग करता है। हालाँकि इसमें कई प्रेषण हैं। | ||
== यह भी देखें == | == यह भी देखें == | ||
* [[नाजुक बाइनरी इंटरफ़ेस समस्या]] | * [[नाजुक बाइनरी इंटरफ़ेस समस्या|फ़्रैजाइल् बाइनरी इंटरफेस समस्या]] | ||
* [[कार्यान्वयन विरासत]] | * [[कार्यान्वयन विरासत|कार्यान्वयन इनहेरिटेंस]] | ||
* [[वंशानुक्रम शब्दार्थ]] | * [[वंशानुक्रम शब्दार्थ|इनहेरिटेंस शब्दार्थ]] | ||
* [[सॉफ्टवेयर भंगुरता]] | * [[सॉफ्टवेयर भंगुरता|सॉफ्टवेयर दुर्बलता]] | ||
* [[आभासी विरासत]] | * [[आभासी विरासत|आभासी इनहेरिटेंस]] | ||
==संदर्भ== | ==संदर्भ== | ||
| Line 80: | 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}} | {{DEFAULTSORT:Fragile Base Class}} | ||
[[Category: Machine Translated Page]] | [[Category:Created On 16/02/2023|Fragile Base Class]] | ||
[[Category: | [[Category:Machine Translated Page|Fragile Base Class]] | ||
[[Category:Pages with script errors|Fragile Base Class]] | |||
[[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() विधि जोड़ते हैं, तो क्लाइंट कोड का पुन: संकलन गलत गतिविधि के अतिरिक्त संकलन त्रुटि देगा।
- कोटलिन में कक्षाएं और विधियां डिफ़ॉल्ट रूप से अंतिम होती हैं। क्लास वंशानुक्रम को सक्षम करने के लिए, क्लास को खुले संशोधक के साथ चिह्नित किया जाना चाहिए। इसी तरह, विधि को ओवरराइड करने की स्वीकृति देने के लिए एक विधि को ओपन के रूप में चिह्नित किया जाना चाहिए।
- जूलिया (प्रोग्राम भाषा) अमूर्त प्रकारों के केवल उप-प्रकार की स्वीकृति देता है और इनहेरिटेंस (वस्तु-उन्मुख प्रोग्राम) के विकल्प के रूप में रचना का उपयोग करता है। हालाँकि इसमें कई प्रेषण हैं।
यह भी देखें
- फ़्रैजाइल् बाइनरी इंटरफेस समस्या
- कार्यान्वयन इनहेरिटेंस
- इनहेरिटेंस शब्दार्थ
- सॉफ्टवेयर दुर्बलता
- आभासी इनहेरिटेंस
संदर्भ
बाहरी संबंध
- Mikhajlov, Leonid; Sekerinski, Emil (1998). "ECOOP'98 — Object-Oriented Programming" (PDF). ECOOP’98 — Object-Oriented Programming. ECOOP 1998. LCNS. Vol. 1445. pp. 355–382. doi:10.1007/BFb0054099. ISBN 978-3-540-64737-9. ISSN 0302-9743. QID 29543920. Retrieved 2020-07-21.
- Holub, Allen (August 1, 2003). "Why extends is evil". Java Toolbox. JavaWorld. Retrieved 2020-07-21.
