इनहेरिटेंस (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)
(वस्तु-उन्मुख प्रोग्रामिंग) में, इनहेरिटेंस एक वस्तु या क्लास को किसी अन्य वस्तु (प्रोटोटाइप-आधारित इनहेरिटेंस) या क्लास (क्लास-बेस्ड इनहेरिटेंस) पर आधारित करने का तंत्र है, समान कार्यान्वयन को बनाए रखता है। सुपर क्लास या बेस क्लास जैसे सम्मिलित क्लास से नई क्लास (सब-क्लास) प्राप्त करने और फिर उन्हें क्लास के पदानुक्रम में बनाने के रूप में भी परिभाषित किया गया है। अधिकांश क्लास-आधारित वस्तु-उन्मुख भाषाओं में, इनहेरिटेंस के माध्यम से बनाई गई एक वस्तु, एक "चाइल्ड ऑब्जेक्ट", निर्माणकर्ता डिस्ट्रक्टर, ओवरलोडेड ऑपरेटरों और बेस क्लास के फ्रेंड फंक्शन के अपवाद के साथ "पैरेंट ऑब्जेक्ट" के सभी गुणों और गतिविधि को प्राप्त करती है। इनहेरिटेंस प्रोग्रामर को सम्मिलित क्लास पर निर्मित क्लास बनाने की अनुमति देता है,[1] जो कोड का पुन: उपयोग करने और स्वतंत्र रूप से सार्वजनिक क्लास और इंटरफेस के माध्यम से मूल सॉफ़्टवेयर का विस्तार करने के लिए समान गतिविधि ( इंटरफ़ेस को अनुभव करते हुए) को बनाए रखते हुए एक नया कार्यान्वयन निर्दिष्ट करने के लिए सम्मिलित क्लास पर बनाया गया है। इनहेरिटेंस के माध्यम से वस्तुओं या क्लास के संबंध एक निर्देशित अचक्रीय ग्राफ को उत्पन्न करते हैं।
एक इनहेरिटेड क्लास को उसके पैरेंट क्लास या सुपर क्लास का सबक्लास कहा जाता है। शब्द "इनहेरिटेंस" का उपयोग क्लास-आधारित और प्रोटोटाइप-आधारित प्रोग्रामिंग दोनों के लिए शिथिल रूप से किया जाता है, लेकिन संकीर्ण उपयोग में यह शब्द क्लास-आधारित प्रोग्रामिंग (एक क्लास दूसरे से इनहेरिटेंस में मिला) के लिए आरक्षित है, प्रोटोटाइप-आधारित प्रोग्रामिंग में संबंधित तकनीक के साथ इसके बजाय प्रत्यायोजन कहा जाता है (एक वस्तु दूसरे को प्रतिनिधि करता है)। क्लास-मॉडिफाइंग इनहेरिटेंस पैटर्न को सरल नेटवर्क इंटरफ़ेस पैरामीटर के अनुसार पूर्व-परिभाषित किया जा सकता है जैसे कि अंतर-भाषा संगतता संरक्षित है।[2][3]
इनहेरिटेंस को सबटाइपिंग के साथ भ्रमित नहीं होना चाहिए।[4][5] कुछ भाषाओं में इनहेरिटेंस और सबटाइपिंग सहमत हैं,[lower-alpha 1] जबकि अन्य में वे भिन्न हैं; सामान्य रूप से, उप-टाइपिंग एक संबंध स्थापित करता है, जबकि इनहेरिटेंस केवल कार्यान्वयन का पुन: उपयोग करता है और एक सिमेंटिक संबंध स्थापित करता है, जरूरी नहीं कि एक सिमेंटिक संबंध हो (इनहेरिटेंस व्यवहार सबटाइपिंग सुनिश्चित नहीं करता है)। इन अवधारणाओं को अलग करने के लिए, सबटाइपिंग को कभी-कभी इंटरफ़ेस इनहेरिटेंस के रूप में संदर्भित किया जाता है (यह स्वीकार किए बिना कि प्रकार चर का विशेषज्ञता भी एक सबटाइपिंग संबंध को प्रेरित करता है), जबकि यहाँ परिभाषित इनहेरिटेंस को कार्यान्वयन इनहेरिटेंस या कोड इनहेरिटेंस के रूप में जाना जाता है।[6] फिर भी, इनहेरिटेंस सबटाइपिंग संबंधों को स्थापित करने के लिए सामान्य रूप से इस्तेमाल किया जाने वाला तंत्र है।[7]
इनहेरिटेंस वस्तु संरचना के विपरीत है, जहां एक वस्तु में दूसरी वस्तु होती है (या एक क्लास की वस्तुओं में दूसरी क्लास की वस्तुएं होती हैं); इनहेरिटेंस पर रचना देखें। उप-टाइपिंग एक संबंध के विपरीत रचना एक संबंध को लागू करती है।
इतिहास
1966 में, टोनी होरे ने रिकॉर्ड्स पर कुछ टिप्पणियां प्रस्तुत कीं, और विशेष रूप से रिकॉर्ड सबक्लास के विचार प्रस्तुत किए, सामान्य गुणों के साथ रिकॉर्ड प्रकार लेकिन एक संस्करण टैग द्वारा विभेदीकृत किया गया और संस्करण के लिए निजी क्षेत्र थे।[8] इससे प्रभावित होकर, 1967 में ओले-जोहान डाहल और क्रिस्टन न्यागार्ड ने एक ऐसा डिज़ाइन प्रस्तुत किया, जिसमें उन वस्तुओं को निर्दिष्ट करने की अनुमति दी गई जो विभिन्न क्लास से संबंधित थीं, लेकिन उनमें सामान्य गुण थे।सामान्य गुणों को एक सुपरक्लास में एकत्र किया गया था, और प्रत्येक सुपरक्लास में संभावित रूप से एक सुपरक्लास हो सकता है। एक सबक्लास के मान इस प्रकार मिश्रित वस्तुएं थी, जिसमें विभिन्न सुपरक्लास से संबंधित कुछ उपसर्ग भागो के साथ ही सबक्लास से संबंधित एक मुख्य भाग सम्मिलित था। ये सभी भाग आपस में जुड़े हुए थे।[9] एक संयुक्त वस्तु के गुण बिंदु संकेतन द्वारा अभिगम्य होंगे। इस विचार को सबसे पहले सिमुला 67 प्रोग्रामिंग भाषा में स्वीकार किया गया था।[10] यह विचार तब स्मॉलटाक, C ++, जावा (प्रोग्रामिंग भाषा), पायथन (प्रोग्रामिंग भाषा), और कई अन्य भाषाओं में विस्तारित हो गया।
प्रकार
प्रतिमान और विशिष्ट भाषा के आधार पर इनहेरिटेंस के विभिन्न प्रकार होते हैं।[11]
- एकल इनहेरिटेंस
- जहां सबक्लास को एक सुपरक्लास की विशेषताएं इनहेरिटेंस में मिलती हैं। एक क्लास से दूसरे क्लास के गुण प्राप्त करता है।
एकाधिक इनहेरिटेंस
- जहाँ एक क्लास में एक से अधिक सुपरक्लास हो सकते हैं और सभी पैरेंट क्लास से सुविधाएँ प्राप्त कर सकते हैं।
"एकाधिक इनहेरिटेंस ... व्यापक रूप से कुशलता से लागू करने के लिए बहुत मुश्किल माना जाता था। उदाहरण के लिए, ऑब्जेक्टिव C पर अपनी पुस्तक में C ++ के सारांश में, ब्रैड कॉक्स ने वास्तव में दावा किया था कि C ++ में एकाधिक इनहेरिटेंस जोड़ना असंभव था। इस प्रकार, एकाधिक इनहेरिटेंस एक चुनौती से अधिक लग रहा था। चूंकि मैंने 1982 की प्रारंभ में कई इनहेरिटेंस पर विचार किया था और 1984 में एक सरल और कुशल कार्यान्वयन तकनीक पाई, मैं चुनौती का विरोध नहीं कर सका। मुझे संदेह है कि यह एकमात्र स्थिति है जिसमें फैशन ने घटनाओं के अनुक्रम को प्रभावित किया[12]
बहुस्तरीय इनहेरिटेंस
- जहां एक सबक्लास दूसरे सबक्लास से इनहेरिटेंस में मिला है। यह असामान्य नहीं है कि एक क्लास किसी अन्य व्युत्पन्न क्लास से प्राप्त होता है जैसा कि ''बहुस्तरीय इनहेरिटेंस'' में दिखाया गया है।
- : क्लास A व्युत्पन्न क्लास B के लिए आधार क्लास के रूप में फ़ंक्शन करता है, जो बदले में व्युत्पन्न क्लास C के लिए आधार क्लास के रूप में फ़ंक्शन करता है। क्लास B को मध्यवर्ती बेस क्लास के रूप में जाना जाता है क्योंकि यह A और C के बीच इनहेरिटेंस के लिए एक लिंक प्रदान करता है। श्रृंखला ABC को इनहेरिटेंस पथ के रूप में जाना जाता है।
- बहुस्तरीय इनहेरिटेंस के साथ एक व्युत्पन्न क्लास निम्नानुसार घोषित किया गया है:
class A { ... }; // Base class
class B : public A { ... }; // B derived from A
class C : public B { ... }; // C derived from B
- इस प्रक्रिया को किसी भी स्तर तक बढ़ाया जा सकता है।
- वर्गीकृत इनहेरिटेंस
- यह वह जगह है जहां एक क्लास एक से अधिक सब-क्लास के लिए सुपरक्लास (बेस क्लास) के रूप में फ़ंक्शन करता है। उदाहरण के लिए, एक पैरेंट क्लास, A, के दो सबक्लास B और C हो सकते हैं। B और C दोनों के पैरेंट क्लास A हैं, लेकिन B और C दो अलग-अलग सबक्लास हैं।
- हाइब्रिड इनहेरिटेंस
- हाइब्रिड इनहेरिटेंस तब होता है जब उपरोक्त दो या दो से अधिक प्रकार की इनहेरिटेंस का संयोजन होता है। इसका एक उदाहरण है जब क्लास A में सबक्लास B होता है जिसमें दो सबक्लास C और डी होते हैं। यह बहुस्तरीय इनहेरिटेंस और वर्गीकृत इनहेरिटेंस दोनों का संयोजन है।
सबक्लास और अधिवर्ग
सबक्लास, व्युत्पन्न क्लास, उत्तराधिकारी क्लास, या बाल क्लास मॉड्यूलर प्रोग्रामिंग व्युत्पन्न क्लास हैं जो एक या एक से अधिक प्रोग्रामिंग भाषा संस्थाओं को एक या अधिक अन्य क्लास (सुपरक्लास, बेस क्लास या पैरेंट क्लास कहा जाता है) से प्राप्त करते हैं। क्लास इनहेरिटेंस के शब्दार्थ भाषा से भाषा में भिन्न होते हैं, लेकिन सामान्य रूप से सबक्लास स्वचालित रूप से अपने सुपरक्लास के उदाहरण चर और सदस्य फ़ंक्शन को प्राप्त करता है।
व्युत्पन्न क्लास को परिभाषित करने का सामान्य रूप है:[13]
class SubClass: visibility SuperClass
{
// subclass members
};
- कोलन इंगित करता है कि सबक्लास सुपरक्लास से इनहेरिटेंस में मिला है। दृश्यता वैकल्पिक है और, यदि सम्मिलित है, तो निजी या सार्वजनिक हो सकती है। डिफ़ॉल्ट दृश्यता निजी है। दृश्यता निर्दिष्ट करती है कि आधार क्लास की विशेषताएं निजी रूप से व्युत्पन्न हैं या सार्वजनिक रूप से व्युत्पन्न हैं।
कुछ भाषाएँ अन्य निर्माणों की इनहेरिटेंस का भी समर्थन करती हैं। उदाहरण के लिए, एफिल (प्रोग्रामिंग भाषा) में, डिज़ाइन द्वारा अनुबंध जो एक क्लास के विनिर्देश को परिभाषित करता है, वारिसों द्वारा भी इनहेरिटेंस में मिला है। सुपरक्लास एक सामान्य इंटरफ़ेस और मूलभूत कार्यक्षमता स्थापित करता है, जो विशेष सबक्लास इनहेरिट, संशोधित और पूरक कर सकते हैं। सबक्लास द्वारा इनहेरिटेंस में मिले सॉफ़्टवेयर को सबक्लास में पुन: प्रयोज्य माना जाता है। किसी क्लास के उदाहरण का संदर्भ वास्तव में उसके सबक्लास में से एक का संदर्भ दे सकता है। संदर्भित वस्तु का वास्तविक क्लास संकलन-समय पर भविष्यवाणी करना असंभव है। कई अलग-अलग क्लास की वस्तुओं के सदस्य फ़ंक्शन को लागू करने के लिए एक समान इंटरफ़ेस का उपयोग किया जाता है। सबक्लास सुपरक्लास फ़ंक्शन को पूरी तरह से नए फ़ंक्शन से बदल सकते हैं जो समान विधि हस्ताक्षर साझा करते हैं।
गैर-उपवर्गीय क्लास
कुछ भाषाओं में एक क्लास को क्लास (कंप्यूटर प्रोग्रामिंग)#नॉन-सबक्लासेबल|नॉन-सबक्लासेबल के रूप में क्लास डिक्लेरेशन में कुछ क्लास संशोधक्स जोड़कर घोषित किया जा सकता है। उदाहरणों में शामिल हैं final फ़ाइनल (जावा) और C++ 11 के बाद या बाद में कीवर्ड sealed C # में कीवर्ड। इस तरह के संशोधक क्लास घोषणा से पहले जोड़े जाते हैं class कीवर्ड और क्लास पहचानकर्ता घोषणा। ऐसे गैर-उपवर्गीय क्लास पुन: प्रयोज्यता को प्रतिबंधित करते हैं, खासकर जब डेवलपर्स के पास केवल पूर्वनिर्मित बाइनरी फ़ाइल तक पहुंच होती है और स्रोत कोड नहीं।
एक गैर-उपवर्गीय क्लास में कोई सबक्लास नहीं होता है, इसलिए संकलन समय पर यह आसानी से निकाला जा सकता है कि उस क्लास की वस्तुओं के संदर्भ या संकेत वास्तव में उस क्लास के उदाहरणों को संदर्भित कर रहे हैं और सबक्लास के उदाहरण नहीं हैं (वे सम्मिलित नहीं हैं) या सुपरक्लास के उदाहरण (संदर्भ प्रकार को upcasting करना प्रकार प्रणाली का उल्लंघन करता है)। चूंकि संदर्भित वस्तु का सटीक प्रकार निष्पादन से पहले जाना जाता है, प्रारंभिक बाध्यकारी (स्थैतिक प्रेषण भी कहा जाता है) का उपयोग देर से बाध्यकारी (जिसे गतिशील प्रेषण भी कहा जाता है) के बजाय किया जा सकता है, जिसके लिए एकाधिक इनहेरिटेंस के आधार पर एक या अधिक वर्चुअल विधि तालिका लुकअप की आवश्यकता होती है या उपयोग की जा रही प्रोग्रामिंग भाषा में केवल एक इनहेरिटेंस का समर्थन किया जाता है।
गैर-अतिव्यापी तरीके
जैसे क्लास गैर-उपवर्गीय हो सकती हैं, विधि घोषणाओं में विधि संशोधक हो सकते हैं जो विधि को ओवरराइड होने से रोकते हैं (यानी एक ही नाम के साथ एक नए फ़ंक्शन के साथ प्रतिस्थापित किया जाता है और सबक्लास में हस्ताक्षर टाइप करता है)। एक एनकैप्सुलेशन ((वस्तु-उन्मुख प्रोग्रामिंग) ) # सूचना छिपाने की तंत्र विधि के रूप में गैर-अतिव्यापी है, क्योंकि यह क्लास के अलावा अन्य क्लास द्वारा सुलभ नहीं है, यह एक सदस्य फ़ंक्शन है (यह C ++ के लिए सच नहीं है, हालांकि)। A final जावा में विधि, A sealed C # या A में विधि frozen एफिल में फीचर को ओवरराइड नहीं किया जा सकता है।
आभासी तरीके
यदि सुपरक्लास विधि एक आभासी विधि है, तो सुपरक्लास विधि का आह्वान डायनेमिक डिस्पैच होगा। कुछ भाषाओं के लिए आवश्यक है कि विधियों को विशेष रूप से वर्चुअल घोषित किया जाए (जैसे C ++), और अन्य में, सभी विधियाँ वर्चुअल (जैसे Java) हैं। एक गैर-आभासी विधि का एक आमंत्रण हमेशा स्थिर रूप से प्रेषित किया जाएगा (यानी फ़ंक्शन कॉल का पता संकलन-समय पर निर्धारित किया जाता है)। स्टेटिक डिस्पैच डायनेमिक डिस्पैच की तुलना में तेज़ है और इनलाइन विस्तार जैसे अनुकूलन की अनुमति देता है।
इनहेरिटेंस में मिले सदस्यों की दृश्यता
निम्न तालिका से पता चलता है कि C ++ द्वारा स्थापित शब्दावली का उपयोग करते हुए, क्लास को प्राप्त करते समय दी गई दृश्यता पर कौन से चर और फ़ंक्शन इनहेरिटेंस में मिलते हैं।[14]
| बेस क्लास दृश्यता | व्युत्पन्न क्लास दृश्यता | ||
|---|---|---|---|
| निजी व्युत्पत्ति | संरक्षित व्युत्पत्ति | सार्वजनिक व्युत्पत्ति | |
|
|
|
|
अनुप्रयोग
इनहेरिटेंस का उपयोग दो या दो से अधिक क्लास को एक दूसरे से सह-संबंधित करने के लिए किया जाता है।
ओवरराइडिंग
वस्तु-उन्मुख प्रोग्रामिंग भाषाओं की सूची सूची | (वस्तु-उन्मुख प्रोग्रामिंग) भाषा एक क्लास या वस्तु को एक पहलू के कार्यान्वयन को बदलने की अनुमति देती हैं - सामान्य रूप से एक व्यवहार - जो इसे इनहेरिटेंस में मिला है। इस प्रक्रिया को ओवरराइडिंग विधि कहा जाता है। ओवरराइडिंग एक जटिलता का परिचय देती है: व्यवहार का कौन सा संस्करण इनहेरिटेंस में मिले क्लास का उपयोग करता है - वह जो अपनी क्लास का हिस्सा है, या माता-पिता (आधार) क्लास से एक है? उत्तर प्रोग्रामिंग भाषाओं के बीच भिन्न होता है, और कुछ भाषाएं यह इंगित करने की क्षमता प्रदान करती हैं कि एक विशेष व्यवहार को ओवरराइड नहीं किया जाना चाहिए और बेस क्लास द्वारा परिभाषित व्यवहार करना चाहिए। उदाहरण के लिए, C # में, आधार विधि या संपत्ति को उप-क्लास में केवल ओवरराइड किया जा सकता है यदि इसे वर्चुअल, सार, या ओवरराइड संशोधक के साथ चिह्नित किया गया हो, जबकि प्रोग्रामिंग भाषाओं जैसे जावा में, अन्य विधियों को ओवरराइड करने के लिए विभिन्न विधियों को बुलाया जा सकता है।[15] ओवरराइडिंग का एक विकल्प इनहेरिटेंस में मिले कोड को छिपाना (प्रोग्रामिंग) करना है।
कोड पुन: उपयोग
इंप्लीमेंटेशन इनहेरिटेंस वह तंत्र है जिसके द्वारा एक सबक्लास कोड का पुन: उपयोग करता है | एक आधार क्लास में कोड का पुन: उपयोग करता है। डिफ़ॉल्ट रूप से सबक्लास आधार क्लास के सभी फ़ंक्शन को बनाए रखता है, लेकिन सबक्लास कुछ या सभी फ़ंक्शन को ओवरराइड कर सकता है, आधार क्लास के कार्यान्वयन को अपने आप से बदल सकता है।
निम्नलिखित पायथन उदाहरण में, सबक्लास SquareSumComputer और CubeSumComputer ओवरराइड करें transform() आधार क्लास की विधि SumComputer. बेस क्लास में दो पूर्णांकों के बीच क्लास संख्या के योग की गणना करने के लिए ऑपरेशन शामिल हैं। सबक्लास बेस क्लास की सभी कार्यक्षमताओं का पुन: उपयोग करता है, ऑपरेशन के अपवाद के साथ जो किसी संख्या को उसके क्लास में बदल देता है, इसे एक ऐसे ऑपरेशन से बदल देता है जो एक संख्या को उसके क्लास संख्या और घन संख्या में क्रमशः बदल देता है। सबक्लास इसलिए दो पूर्णांकों के बीच क्लास/घनों के योग की गणना करते हैं।
नीचे पायथन का एक उदाहरण है।
class SumComputer:
def __init__(self, a, b):
self.a = a
self.b = b
def transform(self, x):
raise NotImplementedError
def inputs(self):
return range(self.a, self.b)
def compute(self):
return sum(self.transform(value) for value in self.inputs())
class SquareSumComputer(SumComputer):
def transform(self, x):
return x * x
class CubeSumComputer(SumComputer):
def transform(self, x):
return x * x * x
अधिकांश तिमाहियों में, कोड पुन: उपयोग के एकमात्र उद्देश्य के लिए क्लास इनहेरिटेंस पक्ष से बाहर हो गई है।[citation needed] प्राथमिक चिंता यह है कि कार्यान्वयन इनहेरिटेंस वस्तु-उन्मुख प्रोग्रामिंग प्रतिस्थापन क्षमता में बहुरूपता का कोई आश्वासन प्रदान नहीं करता है - पुन: उपयोग करने वाले क्लास का एक उदाहरण इनहेरिटेंस में मिले क्लास के उदाहरण के लिए आवश्यक रूप से प्रतिस्थापित नहीं किया जा सकता है। एक वैकल्पिक तकनीक, स्पष्ट प्रत्यायोजन पैटर्न के लिए अधिक प्रोग्रामिंग प्रयास की आवश्यकता होती है, लेकिन प्रतिस्थापनीयता के मुद्दे से बचा जाता है।[citation needed] C ++ में निजी इनहेरिटेंस को प्रतिस्थापन योग्यता के बिना कार्यान्वयन इनहेरिटेंस के रूप में उपयोग किया जा सकता है। जबकि सार्वजनिक इनहेरिटेंस एक रिश्ते का प्रतिनिधित्व करती है और प्रत्यायोजन एक रिश्ते का प्रतिनिधित्व करता है, निजी (और संरक्षित) इनहेरिटेंस को रिश्ते के संदर्भ में लागू किया जा सकता है।[16]
इनहेरिटेंस का एक और लगातार उपयोग यह गारंटी देना है कि क्लास एक निश्चित सामान्य इंटरफ़ेस बनाए रखती हैं; अर्थात्, वे समान विधियों को लागू करते हैं। मूल क्लास कार्यान्वित संचालन और संचालन का एक संयोजन हो सकता है जिसे बाल क्लास में लागू किया जाना है। अक्सर, सुपरटाइप और सबटाइपिंग के बीच कोई इंटरफ़ेस परिवर्तन नहीं होता है- बच्चा अपने मूल क्लास के बजाय वर्णित व्यवहार को लागू करता है।[17]
इनहेरिटेंस बनाम सबटाइपिंग
इनहेरिटेंस समान है लेकिन सबटाइपिंग से अलग है।[4]सबटाइपिंग किसी दिए गए प्रकार को दूसरे प्रकार या अमूर्त के लिए प्रतिस्थापित करने में सक्षम बनाता है, और कहा जाता है कि भाषा समर्थन के आधार पर, उप-प्रकार और कुछ मौजूदा अमूर्तता के बीच एक संबंध स्थापित करने के लिए, या तो स्पष्ट रूप से या स्पष्ट रूप से। रिश्ते को उन भाषाओं में इनहेरिटेंस के माध्यम से स्पष्ट रूप से व्यक्त किया जा सकता है जो सबटाइपिंग तंत्र के रूप में इनहेरिटेंस का समर्थन करते हैं। उदाहरण के लिए, निम्नलिखित C ++ कोड क्लास B और A के बीच एक स्पष्ट इनहेरिटेंस संबंध स्थापित करता है, जहां B A के उप-क्लास और उप-प्रकार दोनों है, और A के रूप में इस्तेमाल किया जा सकता है जहां B निर्दिष्ट किया गया है (एक संदर्भ के माध्यम से, एक सूचक या वस्तु ही)।
class A {
public:
void DoSomethingALike() const {}
};
class B : public A {
public:
void DoSomethingBLike() const {}
};
void UseAnA(const A& a) {
a.DoSomethingALike();
}
void SomeFunc() {
B b;
UseAnA(b); // b can be substituted for an A.
}
प्रोग्रामिंग भाषाओं में जो एक सबटाइपिंग बहुरूपता के रूप में इनहेरिटेंस का समर्थन नहीं करते हैं, डेटा प्रकार के बीच संबंध की तुलना में आधार क्लास और व्युत्पन्न क्लास के बीच संबंध केवल कार्यान्वयन (कोड पुन: उपयोग के लिए एक तंत्र) के बीच संबंध है। इनहेरिटेंस , यहां तक कि प्रोग्रामिंग भाषाओं में भी जो एक सबटाइपिंग तंत्र के रूप में इनहेरिटेंस का समर्थन करते हैं, आवश्यक रूप से व्यवहारिक सबटाइपिंग की आवश्यकता नहीं है। एक क्लास को प्राप्त करना पूरी तरह से संभव है जिसका वस्तु गलत तरीके से व्यवहार करेगा जब उस संदर्भ में उपयोग किया जाता है जहां मूल क्लास की अपेक्षा की जाती है; लिस्कोव प्रतिस्थापन सिद्धांत देखें।
[18] (संकेत (लाक्षणिकता) की तुलना करें। अर्थ/निरूपण।) कुछ ओओपी भाषाओं में, कोड पुन: उपयोग और सबटाइपिंग की धारणा मेल खाती है क्योंकि एक सबटाइपिंग घोषित करने का एकमात्र तरीका एक नए क्लास को परिभाषित करना है जो दूसरे के कार्यान्वयन को प्राप्त करता है।
डिजाइन की कमी
एक कार्यक्रम को डिजाइन करने में इनहेरिटेंस का बड़े पैमाने पर उपयोग कुछ बाधाओं को लागू करता है।
उदाहरण के लिए, एक क्लास पर विचार करें Person जिसमें व्यक्ति का नाम, जन्म तिथि, पता और फोन नंबर होता है। हम एक सबक्लास को परिभाषित कर सकते हैं Person बुलाया Student जिसमें व्यक्ति का ग्रेड बिंदु औसत और ली गई क्लास, और का एक अन्य सबक्लास शामिल है Person बुलाया Employee जिसमें व्यक्ति का पद-शीर्षक, नियोक्ता और वेतन शामिल होता है।
इस इनहेरिटेंस पदानुक्रम को परिभाषित करने में हमने पहले ही कुछ प्रतिबंधों को परिभाषित कर दिया है, जिनमें से सभी वांछनीय नहीं हैं:
- Singleness
- सिंगल इनहेरिटेंस का उपयोग करके, एक सबक्लास केवल एक सुपरक्लास से इनहेरिट कर सकता है। ऊपर दिए गए उदाहरण को जारी रखते हुए, a Person वस्तु या तो एक हो सकती है Student या एक Employee, लेकिन दोनों नहीं। एकाधिक इनहेरिटेंस का उपयोग आंशिक रूप से इस समस्या को हल करता है, जैसा कि तब परिभाषित किया जा सकता है StudentEmployee क्लास जो दोनों से इनहेरिटेंस में मिला है Student और Employee. हालांकि, अधिकांश कार्यान्वयनों में, यह अभी भी प्रत्येक सुपरक्लास से केवल एक बार इनहेरिट कर सकता है, और इस प्रकार, उन मामलों का समर्थन नहीं करता है जिनमें एक छात्र के पास दो नौकरियां हैं या दो संस्थानों में भाग लेता है। एफिल में उपलब्ध इनहेरिटेंस मॉडल हीरा समस्या के समर्थन के माध्यम से इसे संभव बनाता है।
स्थिर: किसी वस्तु का इनहेरिटेंस पदानुक्रम उदाहरण (कंप्यूटर विज्ञान) पर तय होता है जब वस्तु का प्रकार चुना जाता है और समय के साथ नहीं बदलता है। उदाहरण के लिए, इनहेरिटेंस ग्राफ a की अनुमति नहीं देता है Student बनने की वस्तु Employee इसकी स्थिति को बनाए रखते हुए वस्तु Person superclass. (इस तरह का व्यवहार, हालांकि, डेकोरेटर पैटर्न के साथ प्राप्त किया जा सकता है।) कुछ ने इनहेरिटेंस की आलोचना की है, यह तर्क देते हुए कि यह डेवलपर्स को उनके मूल डिजाइन मानकों में बंद कर देता है।[19] दृश्यता: जब भी क्लाइंट कोड की किसी वस्तु तक पहुंच होती है, तो सामान्य रूप से वस्तु के सभी सुपरक्लास डेटा तक उसकी पहुंच होती है। यहां तक कि अगर सुपरक्लास को सार्वजनिक घोषित नहीं किया गया है, तो क्लाइंट अभी भी टाइपकास्ट (प्रोग्रामिंग) वस्तु को अपने सुपरक्लास प्रकार में कर सकता है। उदाहरण के लिए, फ़ंक्शन को पॉइंटर देने का कोई तरीका नहीं है Studentका ग्रेड पॉइंट औसत और ट्रांसक्रिप्ट भी उस फ़ंक्शन को छात्र में संग्रहीत सभी व्यक्तिगत डेटा तक पहुंच प्रदान किए बिना Person superclass. C ++ और जावा सहित कई आधुनिक भाषाएं, एक संरक्षित एक्सेस संशोधक प्रदान करती हैं जो सबक्लास को डेटा तक पहुंचने की अनुमति देता है, बिना किसी कोड को इनहेरिटेंस की श्रृंखला के इसे एक्सेस करने की अनुमति देता है।
समग्र पुन: उपयोग सिद्धांत इनहेरिटेंस का एक विकल्प है। यह तकनीक प्राथमिक क्लास पदानुक्रम से व्यवहार को अलग करके और किसी व्यावसायिक डोमेन क्लास में आवश्यक विशिष्ट व्यवहार क्लास सहित बहुरूपता और कोड पुन: उपयोग का समर्थन करती है। यह दृष्टिकोण रन टाइम पर व्यवहार संशोधनों की अनुमति देकर एक क्लास पदानुक्रम की स्थिर प्रकृति से बचता है और एक क्लास को अपने पूर्वज क्लास के गतिविधि तक सीमित होने के बजाय बुफे-शैली के व्यवहार को लागू करने की अनुमति देता है।
मुद्दे और विकल्प
कार्यान्वयन इनहेरिटेंस कम से कम 1990 के दशक से प्रोग्रामरों और भूमिका उन्मुख प्रोग्रामिंग के सिद्धांतकारों के बीच विवादास्पद रहा है। उनमें से डिजाइन पैटर्न्स के लेखक हैं, जो इसके बजाय इंटरफ़ेस इनहेरिटेंस की वकालत करते हैं, और इनहेरिटेंस पर रचना का पक्ष लेते हैं। उदाहरण के लिए, क्लास के बीच इनहेरिटेंस की स्थिर प्रकृति को दूर करने के लिए डेकोरेटर पैटर्न (जैसा कि #Design बाधाओं का उल्लेख किया गया है) प्रस्तावित किया गया है। एक ही समस्या के अधिक मौलिक समाधान के रूप में, भूमिका-उन्मुख प्रोग्रामिंग एक नई अवधारणा में इनहेरिटेंस और संरचना के गुणों को जोड़कर, एक विशिष्ट संबंध का परिचय देती है।[citation needed] एलन होलूब के अनुसार, इम्प्लीमेंटेशन इनहेरिटेंस के साथ मुख्य समस्या यह है कि यह फ्रैजाइल बेस क्लास के रूप में अनावश्यक कपलिंग (कंप्यूटर प्रोग्रामिंग) का परिचय देता है। नाजुक आधार क्लास समस्या:[6] बेस क्लास के कार्यान्वयन में संशोधन सबक्लास में अनजाने व्यवहार परिवर्तन का कारण बन सकता है। इंटरफेस का उपयोग इस समस्या से बचा जाता है क्योंकि कोई कार्यान्वयन साझा नहीं किया जाता है, केवल एपीआई।[19] इसे बताने का एक और तरीका यह है कि इनहेरिटेंस एनकैप्सुलेशन ((वस्तु-उन्मुख प्रोग्रामिंग) ) को तोड़ता है।[20] समस्या खुले वस्तु-ओरिएंटेड सिस्टम जैसे सॉफ्टवेयर ढांचा में स्पष्ट रूप से सामने आती है, जहाँ क्लाइंट कोड को सिस्टम-आपूर्ति वाली क्लास से इनहेरिटेंस में मिलने की उम्मीद की जाती है और फिर इसके एल्गोरिदम में सिस्टम की क्लास के लिए प्रतिस्थापित किया जाता है।[6] कथित रूप से, जावा के आविष्कारक जेम्स गोस्लिंग ने कार्यान्वयन इनहेरिटेंस के खिलाफ बात की है, यह कहते हुए कि यदि वह जावा को फिर से डिज़ाइन करना चाहते हैं तो वह इसे शामिल नहीं करेंगे।[19] भाषा डिजाइन जो सबटाइपिंग (इंटरफ़ेस इनहेरिटेंस ) से इनहेरिटेंस को कम करते हैं, 1990 की शुरुआत में दिखाई दिए;[21] इसका एक आधुनिक उदाहरण गो (प्रोग्रामिंग भाषा) प्रोग्रामिंग भाषा है।
जटिल इनहेरिटेंस , या अपर्याप्त रूप से परिपक्व डिजाइन के भीतर उपयोग की जाने वाली इनहेरिटेंस, यो-यो समस्या का कारण बन सकती है। 1990 के दशक के अंत में जब इनहेरिटेंस का उपयोग संरचना कार्यक्रमों के प्राथमिक दृष्टिकोण के रूप में किया गया था, तो डेवलपर्स ने कोड को इनहेरिटेंस की अधिक परतों में तोड़ने का प्रयास किया क्योंकि सिस्टम की कार्यक्षमता बढ़ गई थी। यदि एक विकास दल ने एकल जिम्मेदारी सिद्धांत के साथ इनहेरिटेंस की कई परतों को संयोजित किया, तो इसके परिणामस्वरूप कोड की बहुत पतली परतें बन गईं, जिसमें वास्तविक कोड की केवल 1 या 2 पंक्तियों वाली कई परतें थीं।[citation needed] बहुत C परतें डिबगिंग को एक महत्वपूर्ण चुनौती बनाती हैं, क्योंकि यह निर्धारित करना कठिन हो जाता है कि किस परत को डीबग करने की आवश्यकता है।
इनहेरिटेंस के साथ एक और समस्या यह है कि सबक्लास को कोड में परिभाषित किया जाना चाहिए, जिसका अर्थ है कि प्रोग्राम उपयोगकर्ता रनटाइम पर नए सबक्लास नहीं जोड़ सकते। अन्य डिजाइन पैटर्न (जैसे इकाई-घटक-प्रणाली) कार्यक्रम के उपयोगकर्ताओं को रनटाइम पर एक इकाई की विविधताओं को परिभाषित करने की अनुमति देते हैं।
यह भी देखें
- पुरालेख पैटर्न
- वृत्त-दीर्घवृत्त समस्या
- असफल तर्क - तर्क जो तर्कसंगत रूप से युग्मक है, हालांकि निगमनात्मक रूप से मान्य नहीं है
- इंटरफ़ेस (कंप्यूटिंग) - कंप्यूटर विज्ञान की अवधारणा; दो वस्तुओं के बीच परस्पर क्रिया का बिंदु
- ओवरराइडिंग विधि - वस्तु-उन्मुख प्रोग्रामिंग में भाषा सुविधा
- मिक्सिन - प्रोग्रामिंग अवधारणा
- बहुरूपता (कंप्यूटर विज्ञान) - एक इंटरफ़ेस या प्रतीक का उपयोग कई अलग-अलग प्रकारों के संबंध में
- प्रोटोकॉल - वस्तु-उन्मुख प्रोग्रामिंग में संरचना प्रकार
- भूमिका-उन्मुख प्रोग्रामिंग - वस्तुओं की वैचारिक समझ के आधार पर प्रोग्रामिंग प्रतिमान
- विशेषता (कंप्यूटर प्रोग्रामिंग) - वस्तु-उन्मुख प्रोग्रामिंग में प्रयुक्त अवधारणा
- वर्चुअल इनहेरिटेंस - वस्तु-उन्मुख प्रोग्रामिंग में, इनहेरिटेंस जिसमें सुपरक्लास ऑब्जेक्ट को अप्रत्यक्ष की एक अतिरिक्त स्तर के माध्यम से एक्सेस किया जाता है, जैसे कि डायमंड-आकार बहुस्तरीय इनहेरिटेंस में, सामान्य सुपरक्लास केवल एक बार दिखाई देता है
टिप्पणियाँ
संदर्भ
- ↑ Johnson, Ralph (August 26, 1991). "Designing Reusable Classes" (PDF). www.cse.msu.edu.
- ↑ Madsen, OL (1989). "Virtual classes: A powerful mechanism in object-oriented programming". Conference proceedings on Object-oriented programming systems, languages and applications.
- ↑ Davies, Turk (2021). Advanced Methods and Deep Learning in Computer Vision. Elsevier Science. pp. 179–342.
- ↑ 4.0 4.1 Cook, William R.; Hill, Walter; Canning, Peter S. (1990). Inheritance is not subtyping. Proceedings of the 17th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL). pp. 125–135. CiteSeerX 10.1.1.102.8635. doi:10.1145/96709.96721. ISBN 0-89791-343-4.
- ↑ Cardelli, Luca (1993). Typeful Programming (Technical report). Digital Equipment Corporation. p. 32–33. SRC Research Report 45.
- ↑ 6.0 6.1 6.2 Mikhajlov, Leonid; Sekerinski, Emil (1998). A study of the fragile base class problem (PDF). Proceedings of the 12th European Conference on Object-Oriented Programming (ECOOP). Lecture Notes in Computer Science. Vol. 1445. Springer. pp. 355–382. doi:10.1007/BFb0054099. ISBN 978-3-540-64737-9. Archived from the original (PDF) on 2017-08-13. Retrieved 2015-08-28.
- ↑ Tempero, Ewan; Yang, Hong Yul; Noble, James (2013). What programmers do with inheritance in Java (PDF). ECOOP 2013–Object-Oriented Programming. Lecture Notes in Computer Science. Vol. 7920. Springer. pp. 577–601. doi:10.1007/978-3-642-39038-8_24. ISBN 978-3-642-39038-8.
- ↑ Hoare, C. A. R. (1966). Record Handling (PDF) (Technical report). pp. 15–16.
- ↑ Dahl, Ole-Johan; Nygaard, Kristen (May 1967). Class and subclass declarations (PDF). IFIP Working Conference on Simulation Languages. Oslo: Norwegian Computing Center.
- ↑ Dahl, Ole-Johan (2004). "The Birth of Object Orientation: the Simula Languages" (PDF). From Object-Orientation to Formal Methods. 2635: 15–25. doi:10.1007/978-3-540-39993-3_3.
- ↑ "C++ Inheritance". www.cs.nmsu.edu.
- ↑ Stroustrup, Bjarne (1994). The Design and Evolution of C++. Pearson. p. 417. ISBN 9780135229477.
- ↑ Schildt, Herbert (2003). The complete reference C++. Tata McGraw Hill. p. 417. ISBN 978-0-07-053246-5.
- ↑ Balagurusamy, E. (2010). Object Oriented Programming With C++. Tata McGraw Hill. p. 213. ISBN 978-0-07-066907-9.
- ↑ override(C# Reference)
- ↑ "GotW #60: Exception-Safe Class Design, Part 2: Inheritance". Gotw.ca. Retrieved 2012-08-15.
- ↑ Venugopal, K.R.; Buyya, Rajkumar (2013). Mastering C++. Tata McGraw Hill Education Private Limited. p. 609. ISBN 9781259029943.
- ↑ Mitchell, John (2002). "10 "Concepts in object-oriented languages"". Concepts in programming language. Cambridge University Press. p. 287. ISBN 978-0-521-78098-8.
- ↑ 19.0 19.1 19.2 Holub, Allen (1 August 2003). "Why extends is evil". Retrieved 10 March 2015.
- ↑ Seiter, Linda M.; Palsberg, Jens; Lieberherr, Karl J. (1996). "Evolution of object behavior using context relations". ACM SIGSOFT Software Engineering Notes. 21 (6): 46. CiteSeerX 10.1.1.36.5053. doi:10.1145/250707.239108.
- ↑ America, Pierre (1991). Designing an object-oriented programming language with behavioural subtyping. REX School/Workshop on the Foundations of Object-Oriented Languages. Lecture Notes in Computer Science. Vol. 489. pp. 60–90. doi:10.1007/BFb0019440. ISBN 978-3-540-53931-5.
अग्रिम पठन
- Meyer, Bertrand (1997). "24. Using Inheritance Well". Object-Oriented Software Construction (2nd ed.). Prentice Hall. ISBN 0-13-629155-4.
- Samokhin, Vadim (2017). "Implementation Inheritance Is Evil". HackerNoon. Medium.
