इनहेरिटेंस (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)
ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में, इनहेरिटेंस एक वस्तु या क्लास को किसी अन्य वस्तु (प्रोटोटाइप-आधारित इनहेरिटेंस) या क्लास (क्लास-बेस्ड इनहेरिटेंस) पर आधारित करने का तंत्र है, समान कार्यान्वयन को बनाए रखता है। सुपर क्लास या बेस क्लास जैसे सम्मिलित क्लास से नई क्लास (सब-क्लास) प्राप्त करने और फिर उन्हें क्लास के पदानुक्रम में बनाने के रूप में भी परिभाषित किया गया है। अधिकांश क्लास-आधारित वस्तु-उन्मुख भाषाओं में, इनहेरिटेंस के माध्यम से बनाई गई एक वस्तु, एक "चाइल्ड ऑब्जेक्ट", निर्माणकर्ता डिस्ट्रक्टर, अतिभारित संचालक और बेस क्लास के फ्रेंड फंक्शन के आक्षेप के साथ "पैरेंट ऑब्जेक्ट" के सभी गुणों और गतिविधि को प्राप्त करती है। इनहेरिटेंस प्रोग्रामर को सम्मिलित क्लास पर निर्मित क्लास बनाने की स्वीकृति देता है,[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 और D होते हैं। यह बहुस्तरीय इनहेरिटेंस और वर्गीकृत इनहेरिटेंस दोनों का संयोजन है।
सबक्लास और सुपरक्लास
सबक्लास, व्युत्पन्न क्लास, एर क्लास, या चाइल्ड क्लास मॉड्यूलर प्रोग्रामिंग व्युत्पन्न क्लास हैं जो एक या एक से अधिक प्रोग्रामिंग भाषा संस्थाओं को एक या अधिक अन्य क्लास (सुपरक्लास, बेस क्लास या पैरेंट क्लास कहा जाता है) से प्राप्त करते हैं। क्लास इनहेरिटेंस के शब्दार्थ भाषा से भाषा में भिन्न होते हैं, लेकिन सामान्य रूप से सबक्लास स्वचालित रूप से अपने सुपरक्लास के इंटेन्स वेरिएबल और मेम्बर (सदस्य) फ़ंक्शन को प्राप्त करता है।
व्युत्पन्न क्लास को परिभाषित करने का सामान्य रूप है:[13]
class SubClass: visibility SuperClass
{
// subclass members
};
- कोलन इंगित करता है कि सबक्लास सुपरक्लास से इनहेरिटेंस में मिला है। दृश्यता वैकल्पिक है और, यदि सम्मिलित है, तो निजी या सार्वजनिक हो सकती है। डिफ़ॉल्ट दृश्यता निजी है। दृश्यता निर्दिष्ट करती है कि आधार क्लास की विशेषताएं निजी रूप से व्युत्पन्न हैं या सार्वजनिक रूप से व्युत्पन्न हैं।
कुछ भाषाएँ अन्य निर्माणों की इनहेरिटेंस का भी समर्थन करती हैं। उदाहरण के लिए, एफिल (प्रोग्रामिंग भाषा) में, डिज़ाइन द्वारा अनुबंध जो एक क्लास के विनिर्देश को परिभाषित करता है, एर द्वारा भी इनहेरिटेंस में मिला है। सुपरक्लास एक सामान्य इंटरफ़ेस और मूलभूत कार्यक्षमता स्थापित करता है, जो विशेष सबक्लास इनहेरिट, संशोधित और पूरक कर सकते हैं। सबक्लास द्वारा इनहेरिटेंस में प्राप्त सॉफ़्टवेयर को सबक्लास में पुन: प्रयोज्य माना जाता है। किसी क्लास के इंस्टेंस का संदर्भ वास्तव में उसके सबक्लास में से एक का संदर्भ दे सकता है। संदर्भित वस्तु का वास्तविक क्लास संकलन-समय पर भविष्यवाणी करना असंभव है। कई अलग-अलग क्लास की वस्तुओं के सदस्य फ़ंक्शन को प्रयुक्त करने के लिए एक समान इंटरफ़ेस का उपयोग किया जाता है। सबक्लास सुपरक्लास फ़ंक्शन को पूरी तरह से नए फ़ंक्शन से बदल सकते हैं जो समान विधि हस्ताक्षर साझा करते हैं।
गैर- सबक्लासेसबल क्लास
कुछ भाषाओं में क्लास (कंप्यूटर प्रोग्रामिंग) गैर-सबक्लासेबल के रूप में क्लास प्रकाशन में कुछ क्लास संशोधक जोड़कर घोषित किया जा सकता है। उदाहरणों में जावा और C++ 11 में finalकीवर्ड या C # मे sealed कीवर्ड सम्मिलित है । इस तरह के संशोधक class कीवर्ड और क्लास पहचानकर्ता प्रकाशन से पहले जोड़े जाते है। ऐसे गैर-सबक्लासेस क्लास पुन: प्रयोज्यता को प्रतिबंधित करते हैं, विशेष रूप से जब विकासक के पास केवल पूर्वनिर्मित बाइनरी फ़ाइल तक अभिगम्य और स्रोत कोड नहीं होती है।
एक गैर-उपवर्गीय क्लास में कोई सबक्लास नहीं होता है, इसलिए संकलन समय पर यह आसानी से निकाला जा सकता है कि उस क्लास की वस्तुओं के संदर्भ या संकेत वास्तव में उस क्लास के इंस्टेंस को संदर्भित कर रहे हैं और सबक्लास के इंस्टेंस नहीं हैं (वे सम्मिलित नहीं हैं) या सुपरक्लास के इंस्टेंस (संदर्भ प्रकार को अपकास्ट करना प्रारूप प्रणाली का उल्लंघन करता है)। चूंकि संदर्भित वस्तु का परिशुद्ध प्रारूप निष्पादन से पहले जाना जाता है, प्रारंभिक बाइन्डिंग (स्थिर प्रेषण भी कहा जाता है) का उपयोग देर से बाइंडिंग (जिसे गतिशील प्रेषण भी कहा जाता है) के अतिरिक्त किया जा सकता है, जिसके लिए एकाधिक इनहेरिटेंस के आधार पर एक या अधिक वर्चुअल विधि सारणी जाँचने की आवश्यकता होती है या उपयोग की जा रही प्रोग्रामिंग भाषा में केवल एक इनहेरिटेंस का समर्थन किया जाता है।
गैर-ओवर्रिजेबल तरीके
जैसे क्लास गैर-सबक्लासेसबल हो सकती हैं, विधि प्रकाशन में विधि संशोधक हो सकते हैं जो विधि को ओवरराइड होने से रोकते हैं (अर्थात एक ही नाम के साथ एक नए फ़ंक्शन के साथ प्रतिस्थापित किया जाता है और सबक्लास में प्रारूप संकेत करता है)। निजी विधि गैर-ओवर्रिजेबल है क्योंकि यह क्लास के अतिरिक्त अन्य क्लास द्वारा अभिगम्य योग्य नहीं है, यह मेम्बर फ़ंक्शन है (हालांकि यह C ++ के लिए सत्य नहीं है )। जावा में final विधि, C # में sealedविधि या एफिल में frozen सुविधा को ओवरराइड नहीं किया जा सकता है।
आभासी तरीके
यदि सुपरक्लास विधि एक आभासी विधि है, तो सुपरक्लास विधि का अनुरोध गतिशील रूप से प्रेषित होगा। कुछ भाषाओं के लिए आवश्यक है कि विधियों को विशेष रूप से वर्चुअल घोषित किया जाए (जैसे C ++), और अन्य में, सभी विधियाँ वर्चुअल (जैसे जावा) हैं। एक गैर-आभासी विधि का अनुरोध सदैव स्थिर रूप से प्रेषित किया जाएगा (अर्थात फ़ंक्शन कॉल का पता संकलन-समय पर निर्धारित किया जाता है)। स्थिर प्रेषण गतिशील प्रेषण की तुलना में तेज़ है और इनलाइन विस्तार जैसे अनुकूलन की स्वीकृति देता है।
इनहेरिटेंस में प्राप्त सदस्यों की दृश्यता
निम्न तालिका से पता चलता है कि 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 Ba: 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 पर विचार करें जिसमें एक व्यक्ति का नाम, जन्म तिथि, पता और फोन नंबर सम्मिलित हो। हम Student नामक Person सबक्लास को परिभाषित कर सकते हैं जिसमें व्यक्ति का ग्रेड बिंदु औसत और ली गई क्लास सम्मिलित है, और Employee नामक Person का एक अन्य सबक्लास जिसमें व्यक्ति का नौकरी का शीर्षक, नियोजक और वेतन सम्मिलित है।
इस इनहेरिटेंस पदानुक्रम को परिभाषित करने में हमने पहले ही कुछ प्रतिबंधों को परिभाषित कर दिया है, जिनमें से सभी वांछनीय नहीं हैं:
- एकनिष्ठता
- एकल इनहेरिटेंस का उपयोग करके, एक सबक्लास केवल एक सुपरक्लास से इनहेरिट कर सकता है। ऊपर दिए गए उदाहरण को जारी रखते हुए, एक Person वस्तु या Student या एक Employee हो सकता है, लेकिन दोनों नहीं। एकाधिक इनहेरिटेंस का उपयोग आंशिक रूप से इस समस्या को हल करता है, क्योंकि इसके बाद एक StudentEmployee को परिभाषित किया जा सकता है जो Student और Employee दोनों से प्राप्त होता है। हालांकि, अधिकांश कार्यान्वयनों में, यह अभी भी प्रत्येक सुपरक्लास से केवल एक बार इनहेरिट कर सकता है, और इस प्रकार, उन स्थितियों का समर्थन नहीं करता है जिनमें एक छात्र के पास दो नौकरियां हैं या दो संस्थानों में भाग लेता है। एफिल में उपलब्ध इनहेरिटेंस मॉडल बार-बार इनहेरिटेंस के समर्थन के माध्यम से इसे संभव बनाता है।
स्थिर:
जब वस्तु का प्रकार चयन किया जाता है और समय के साथ नहीं बदलता है, तो किसी वस्तु का इनहेरिटेंस पदानुक्रम तात्कालिकता पर निर्धारित हो जाता है। उदाहरण के लिए, इनहेरिटेंस ग्राफ अपने Person सुपरक्लास की स्थिति को बनाए रखते हुए एक Student बनने की वस्तु Employee वस्तु बनने की स्वीकृति नहीं देता है। (इस तरह का गतिविधि, हालांकि, संचालक स्वरूप के साथ प्राप्त किया जा सकता है।) कुछ ने इनहेरिटेंस की आलोचना की है, यह तर्क देते हुए कि यह विकासक को उनके मूल डिजाइन मानकों में बंद कर देता है।[19]
दृश्यता:
जब भी क्लाइंट कोड की किसी वस्तु तक अभिगम्य होती है, तो सामान्य रूप से वस्तु के सभी सुपरक्लास डेटा तक उसकी अभिगम्य होती है। यहां तक कि यदि सुपरक्लास को सार्वजनिक घोषित नहीं किया गया है, तो क्लाइंट अभी भी टाइपकास्ट (प्रोग्रामिंग) ऑब्जेक्ट को अपने सुपरक्लास प्रकार में कर सकता है। उदाहरण के लिए, Student के Person सुपरक्लास में संग्रहीत सभी व्यक्तिगत डेटा तक उस फ़ंक्शन को अभिगम्य प्रदान किए बिना किसी छात्र के ग्रेड बिंदु औसत और प्रतिलेख के लिए फ़ंक्शन को पॉइंटर देने का कोई तरीका नहीं है। C ++ और जावा समेत कई आधुनिक भाषाएं, एक "संरक्षित" अभिगम्य संशोधक प्रदान करती हैं जो सबक्लास को डेटा तक अभिगम्य की स्वीकृति देती है, बिना किसी कोड को इनहेरिटेंस की श्रृंखला के बाहर पहुंचने की स्वीकृति देता है।
समग्र पुन: उपयोग सिद्धांत इनहेरिटेंस का एक विकल्प है। यह तकनीक प्राथमिक क्लास पदानुक्रम से गतिविधि को अलग करके और किसी व्यावसायिक डोमेन क्लास में आवश्यक विशिष्ट गतिविधि क्लास सहित बहुरूपता और कोड पुन: उपयोग का समर्थन करती है। यह दृष्टिकोण रन टाइम पर गतिविधि संशोधनों की स्वीकृति देकर एक क्लास पदानुक्रम की स्थिर स्वरूप से सुरक्षित है और एक क्लास को अपने अग्रगामी क्लास के गतिविधि तक सीमित होने के अतिरिक्त बुफे-शैली के गतिविधि को प्रयुक्त करने की स्वीकृति देता है।
समस्याएं और विकल्प
कार्यान्वयन इनहेरिटेंस कम से कम 1990 के दशक से प्रोग्रामरों और ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के सिद्धांतकारों के बीच विवादास्पद रहा है। उनमें से डिज़ाइन स्वरूप के लेखक हैं, जो इसके अतिरिक्त इंटरफ़ेस इनहेरिटेंस का समर्थन करते हैं, और इनहेरिटेंस पर रचना का पक्ष लेते हैं। उदाहरण के लिए, क्लास के बीच इनहेरिटेंस की स्थिर प्रकृति को दूर करने के लिए संचालक स्वरूप (जैसा ऊपर बताया गया है) प्रस्तावित किया गया है। एक ही समस्या के अधिक मौलिक समाधान के रूप में, भूमिका-उन्मुख प्रोग्रामिंग एक नई अवधारणा में इनहेरिटेंस और रचना के गुणों के संयोजन से, एक अलग संबंध का परिचय देती है।[citation needed]
एलन होलूब के अनुसार, कार्यान्वयन इनहेरिटेंस के साथ मुख्य समस्या यह है कि यह "फ्रैजल बेस क्लास समस्या" के रूप में अनावश्यक युग्मन का परिचय देता है:[6] बेस क्लास के कार्यान्वयन में संशोधन सबक्लास में असावधान गतिविधि परिवर्तन का कारण बन सकता है। इंटरफेस का उपयोग करने से इस समस्या से बचा जाता है क्योंकि केवल एप्लीकेशन प्रोग्रामिंग इंटरफेस को कोई कार्यान्वयन साझा नहीं किया जाता है[19] इसे बताने का एक और तरीका यह है कि इनहेरिटेंस ब्रेक कैप्सुलन ((ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) ) है।[20] समस्या खुले वस्तु-उन्मुख प्रणाली जैसे सॉफ्टवेयर रूपरेखा में स्पष्ट रूप से सामने आती है, जहाँ क्लाइंट कोड को प्रणाली-आपूर्ति वाली क्लास से इनहेरिटेंस में मिलने की अपेक्षा की जाती है और फिर इसके एल्गोरिदम में प्रणाली की क्लास के लिए प्रतिस्थापित किया जाता है।[6]
कथित रूप से, जावा के आविष्कारक जेम्स गोस्लिंग ने कार्यान्वयन इनहेरिटेंस के विपरीत बात की है, यह कहते हुए कि यदि वह जावा को फिर से डिज़ाइन करना चाहते हैं तो वह इसे सम्मिलित नहीं करेंगे।[19] भाषा डिजाइन जो सबटाइपिंग (इंटरफ़ेस इनहेरिटेंस ) से इनहेरिटेंस को कम करते हैं, 1990 के प्रारंभ में दिखाई दिए;[21] इसका एक आधुनिक उदाहरण गो प्रोग्रामिंग भाषा है।
जटिल इनहेरिटेंस, या अपर्याप्त रूप से समग्र डिजाइन के अंदर उपयोग की जाने वाली इनहेरिटेंस, यो-यो समस्या का कारण बन सकती है। 1990 के दशक के अंत में जब इनहेरिटेंस का उपयोग संरचना प्रोग्राम के प्राथमिक दृष्टिकोण के रूप में किया गया था, तो विकासक ने कोड को इनहेरिटेंस की अधिक स्तरों में विभाजित करने का प्रयास किया क्योंकि प्रणाली की कार्यक्षमता बढ़ गई थी। यदि एक विकास समूह ने एकल दायित्व सिद्धांत के साथ इनहेरिटेंस की कई स्तरों को संयोजित किया, तो इसके परिणामस्वरूप कोड की बहुत पतली परतें बन गईं, जिसमें वास्तविक कोड की केवल 1 या 2 पंक्तियों वाली कई परतें थीं।[citation needed] बहुत सारी परतें डिबगिंग को एक महत्वपूर्ण चुनौती बनाती हैं, क्योंकि यह निर्धारित करना कठिन हो जाता है कि किस परत को डीबग करने की आवश्यकता है।
इनहेरिटेंस के साथ एक और समस्या यह है कि सबक्लास को कोड में परिभाषित किया जाना चाहिए, जिसका अर्थ है कि प्रोग्राम उपयोगकर्ता रनटाइम पर नए सबक्लास नहीं जोड़ सकते। अन्य डिजाइन स्वरूप (जैसे इकाई-घटक-प्रणाली) प्रोग्राम के उपयोगकर्ताओं को रनटाइम पर एक इकाई की विविधताओं को परिभाषित करने की स्वीकृति देते हैं।
यह भी देखें
- पुरालेख स्वरूप
- वृत्त-दीर्घवृत्त समस्या
- असफल तर्क - तर्क जो तर्कसंगत रूप से युग्मक है, हालांकि निगमनात्मक रूप से मान्य नहीं है
- इंटरफ़ेस (कंप्यूटिंग) - कंप्यूटर विज्ञान की अवधारणा; दो वस्तुओं के बीच परस्पर क्रिया का बिंदु
- ओवरराइडिंग विधि - ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में भाषा सुविधा
- मिक्सिन - प्रोग्रामिंग अवधारणा
- बहुरूपता (कंप्यूटर विज्ञान) - एक इंटरफ़ेस या प्रतीक का उपयोग कई अलग-अलग प्रकारों के संबंध में
- प्रोटोकॉल - ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में संरचना प्रकार
- भूमिका-उन्मुख प्रोग्रामिंग - वस्तुओं की वैचारिक समझ के आधार पर प्रोग्रामिंग पद्धति
- विशेषता (कंप्यूटर प्रोग्रामिंग) - ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में प्रयुक्त अवधारणा
- वर्चुअल इनहेरिटेंस - ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में, इनहेरिटेंस जिसमें सुपरक्लास ऑब्जेक्ट को अप्रत्यक्ष की एक अतिरिक्त स्तर के माध्यम से एक्सेस किया जाता है, जैसे कि डायमंड-आकार बहुस्तरीय इनहेरिटेंस में, सामान्य सुपरक्लास केवल एक बार दिखाई देता है
टिप्पणियाँ
संदर्भ
- ↑ 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.
- ↑ Jump up to: 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.
- ↑ Jump up to: 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.
- ↑ Jump up to: 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.
