नाजुक आधार वर्ग: Difference between revisions
m (added Category:Vigyan Ready using HotCat) |
No edit summary |
||
| (One intermediate revision by one other user not shown) | |||
| Line 73: | 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: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: | [[Category:Templates Vigyan Ready|Fragile Base Class]] | ||
[[Category:Vigyan Ready]] | [[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.
