इनहेरिटेंस (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग): Difference between revisions
No edit summary |
|||
| Line 1: | Line 1: | ||
{{Short description|Process of deriving classes from, and organizing them into, a hierarchy}} | {{Short description|Process of deriving classes from, and organizing them into, a hierarchy}} | ||
'''''वस्तु-उन्मुख प्रोग्रामिंग''''' में, इनहेरिटेंस एक वस्तु या क्लास को किसी अन्य वस्तु (प्रोटोटाइप-आधारित इनहेरिटेंस) या क्लास (क्लास-बेस्ड इनहेरिटेंस) पर आधारित करने का तंत्र है, समान कार्यान्वयन को बनाए रखता है। सुपर क्लास या बेस क्लास जैसे सम्मिलित क्लास से नई क्लास (सब-क्लास) प्राप्त करने और फिर उन्हें क्लास के पदानुक्रम में बनाने के रूप में भी परिभाषित किया गया है। अधिकांश क्लास-आधारित वस्तु-उन्मुख भाषाओं में, इनहेरिटेंस के माध्यम से बनाई गई एक वस्तु, एक "चाइल्ड ऑब्जेक्ट", निर्माणकर्ता डिस्ट्रक्टर, अतिभारित संचालक और बेस क्लास के फ्रेंड फंक्शन के आक्षेप के साथ "पैरेंट ऑब्जेक्ट" के सभी गुणों और गतिविधि को प्राप्त करती है। इनहेरिटेंस प्रोग्रामर को सम्मिलित क्लास पर निर्मित क्लास बनाने की स्वीकृति देता है,<ref>{{cite web|url=https://www.cse.msu.edu/~cse870/Input/SS2002/MiniProject/Sources/DRC.pdf |title=Designing Reusable Classes |last=Johnson |first=Ralph |date=August 26, 1991 |website=www.cse.msu.edu }}</ref> जो कोड का पुन: उपयोग करने और स्वतंत्र रूप से सार्वजनिक क्लास और इंटरफेस के माध्यम से मूल सॉफ़्टवेयर का विस्तार करने के लिए समान गतिविधि ( इंटरफ़ेस को अनुभव करते हुए) को बनाए रखते हुए एक नया कार्यान्वयन निर्दिष्ट करने के लिए सम्मिलित क्लास पर बनाया गया है। इनहेरिटेंस के माध्यम से वस्तुओं या क्लास के संबंध एक निर्देशित अचक्रीय ग्राफ को उत्पन्न करते हैं। | |||
एक इनहेरिटेड क्लास को उसके पैरेंट क्लास या सुपर क्लास का सबक्लास कहा जाता है। शब्द "इनहेरिटेंस" का उपयोग क्लास-आधारित और प्रोटोटाइप-आधारित प्रोग्रामिंग दोनों के लिए शिथिल रूप से किया जाता है, लेकिन संकीर्ण उपयोग में यह शब्द क्लास-आधारित प्रोग्रामिंग (एक क्लास दूसरे से इनहेरिटेंस में मिला) के लिए आरक्षित है, प्रोटोटाइप-आधारित प्रोग्रामिंग में संबंधित तकनीक के साथ इसके | एक इनहेरिटेड क्लास को उसके पैरेंट क्लास या सुपर क्लास का सबक्लास कहा जाता है। शब्द "इनहेरिटेंस" का उपयोग क्लास-आधारित और प्रोटोटाइप-आधारित प्रोग्रामिंग दोनों के लिए शिथिल रूप से किया जाता है, लेकिन संकीर्ण उपयोग में यह शब्द क्लास-आधारित प्रोग्रामिंग (एक क्लास दूसरे से इनहेरिटेंस में मिला) के लिए आरक्षित है, प्रोटोटाइप-आधारित प्रोग्रामिंग में संबंधित तकनीक के साथ इसके अतिरिक्त प्रत्यायोजन कहा जाता है (एक वस्तु दूसरे को प्रतिनिधि करता है)। क्लास-मॉडिफाइंग इनहेरिटेंस पैटर्न को सरल नेटवर्क इंटरफ़ेस पैरामीटर के अनुसार पूर्व-परिभाषित किया जा सकता है जैसे कि अंतर-भाषा संगतता संरक्षित है।<ref>{{cite journal |last1=Madsen |first1=OL |title=Virtual classes: A powerful mechanism in object-oriented programming |journal=Conference proceedings on Object-oriented programming systems, languages and applications |date=1989}}</ref><ref>{{cite book |last1=Davies, Turk |title=Advanced Methods and Deep Learning in Computer Vision |date=2021 |publisher=Elsevier Science |pages=179-342}}</ref> | ||
इनहेरिटेंस | इनहेरिटेंस को सबटाइपिंग के साथ भ्रमित नहीं होना चाहिए।<ref name="Cook90">{{Cite conference| last1 = Cook | first1 = William R. | last2 = Hill | first2 = Walter | last3 = Canning | first3 = Peter S. | doi = 10.1145/96709.96721 | title = Inheritance is not subtyping | conference = Proceedings of the 17th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL)| pages = 125–135 | year = 1990 | isbn = 0-89791-343-4 | citeseerx = 10.1.1.102.8635}}</ref><ref>{{cite techreport |first=Luca |last=Cardelli |title=Typeful Programming |number=SRC Research Report 45 |institution=[[Digital Equipment Corporation]] |year=1993 |page=32–33}}</ref> कुछ भाषाओं में इनहेरिटेंस और सबटाइपिंग सहमत हैं,{{efn|This is generally true only in statically-typed class-based OO languages, such as [[C++]], [[C Sharp (programming language)|C#]], Java, and [[Scala (programming language)|Scala]].}} जबकि अन्य में वे भिन्न हैं; सामान्य रूप से, उप-टाइपिंग एक संबंध स्थापित करता है, जबकि इनहेरिटेंस केवल कार्यान्वयन का पुन: उपयोग करता है और एक सिमेंटिक संबंध स्थापित करता है, जरूरी नहीं कि एक सिमेंटिक संबंध हो (इनहेरिटेंस गतिविधि सबटाइपिंग सुनिश्चित नहीं करता है)। इन अवधारणाओं को अलग करने के लिए, सबटाइपिंग को कभी-कभी इंटरफ़ेस इनहेरिटेंस के रूप में संदर्भित किया जाता है (यह स्वीकार किए बिना कि प्रकार चर का विशेषज्ञता भी एक सबटाइपिंग संबंध को प्रेरित करता है), जबकि यहाँ परिभाषित इनहेरिटेंस को कार्यान्वयन इनहेरिटेंस या कोड इनहेरिटेंस के रूप में जाना जाता है।<ref name="Mikhajlov">{{Cite conference| doi = 10.1007/BFb0054099| title = A study of the fragile base class problem| conference = Proceedings of the 12th European Conference on Object-Oriented Programming (ECOOP)| volume = 1445| pages = 355–382| series = Lecture Notes in Computer Science| publisher = Springer| year = 1998| last1 = Mikhajlov| first1 = Leonid| last2 = Sekerinski| first2 = Emil| isbn = 978-3-540-64737-9| url = http://extras.springer.com/2000/978-3-540-67660-7/papers/1445/14450355.pdf| access-date = 2015-08-28| archive-date = 2017-08-13| archive-url = https://web.archive.org/web/20170813041125/http://extras.springer.com/2000/978-3-540-67660-7/papers/1445/14450355.pdf| url-status = dead}}</ref> फिर भी, इनहेरिटेंस सबटाइपिंग संबंधों को स्थापित करने के लिए सामान्य रूप से इस्तेमाल किया जाने वाला तंत्र है।<ref>{{cite conference |last1=Tempero |first1=Ewan |first2=Hong Yul |last2=Yang |first3=James |last3=Noble |title=What programmers do with inheritance in Java |conference=ECOOP 2013–Object-Oriented Programming |year= 2013 |pages=577–601 |url=https://www.cs.auckland.ac.nz/~ewan/qualitas/studies/inheritance/TemperoYangNobleECOOP2013-pre.pdf |doi=10.1007/978-3-642-39038-8_24 |isbn=978-3-642-39038-8 |series=Lecture Notes in Computer Science |volume=7920 |publisher=Springer }}</ref> | ||
इनहेरिटेंस | इनहेरिटेंस वस्तु संरचना के विपरीत है, जहां [[एक]] वस्तु में दूसरी वस्तु होती है (या एक क्लास की वस्तुओं में दूसरी क्लास की वस्तुएं होती हैं); [[वंशानुक्रम पर रचना|इनहेरिटेंस पर रचना]] देखें। उप-टाइपिंग एक संबंध के विपरीत रचना एक संबंध को लागू करती है। | ||
== इतिहास == | == इतिहास == | ||
1966 में, [[टोनी होरे]] ने रिकॉर्ड्स पर कुछ टिप्पणियां प्रस्तुत कीं, और विशेष रूप से रिकॉर्ड सबक्लास के विचार प्रस्तुत किए, सामान्य गुणों के साथ रिकॉर्ड प्रकार लेकिन एक संस्करण टैग द्वारा विभेदीकृत किया गया और संस्करण के लिए निजी क्षेत्र थे।<ref>{{cite techreport |last1=Hoare |first1=C. A. R. |title=Record Handling |date=1966 |url=http://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index/k-9-pdf/k-9-u2293-Record-Handling-Hoare.pdf|pages=15-16}}</ref> इससे प्रभावित होकर, 1967 में [[ओले-जोहान डाहल]] और [[क्रिस्टन न्यागार्ड]] ने एक ऐसा डिज़ाइन प्रस्तुत किया, जिसमें उन वस्तुओं को निर्दिष्ट करने की स्वीकृति दी गई जो विभिन्न क्लास से संबंधित थीं, लेकिन उनमें सामान्य गुण थे।सामान्य गुणों को एक सुपरक्लास में एकत्र किया गया था, और प्रत्येक सुपरक्लास में संभावित रूप से एक सुपरक्लास हो सकता है। एक सबक्लास के मान इस प्रकार मिश्रित वस्तुएं | 1966 में, [[टोनी होरे]] ने रिकॉर्ड्स पर कुछ टिप्पणियां प्रस्तुत कीं, और विशेष रूप से रिकॉर्ड सबक्लास के विचार प्रस्तुत किए, सामान्य गुणों के साथ रिकॉर्ड प्रकार लेकिन एक संस्करण टैग द्वारा विभेदीकृत किया गया और संस्करण के लिए निजी क्षेत्र थे।<ref>{{cite techreport |last1=Hoare |first1=C. A. R. |title=Record Handling |date=1966 |url=http://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index/k-9-pdf/k-9-u2293-Record-Handling-Hoare.pdf|pages=15-16}}</ref> इससे प्रभावित होकर, 1967 में [[ओले-जोहान डाहल]] और [[क्रिस्टन न्यागार्ड]] ने एक ऐसा डिज़ाइन प्रस्तुत किया, जिसमें उन वस्तुओं को निर्दिष्ट करने की स्वीकृति दी गई जो विभिन्न क्लास से संबंधित थीं, लेकिन उनमें सामान्य गुण थे।सामान्य गुणों को एक सुपरक्लास में एकत्र किया गया था, और प्रत्येक सुपरक्लास में संभावित रूप से एक सुपरक्लास हो सकता है। एक सबक्लास के मान इस प्रकार मिश्रित वस्तुएं थी, जिसमें विभिन्न सुपरक्लास से संबंधित कुछ उपसर्ग भागो के साथ ही सबक्लास से संबंधित एक मुख्य भाग सम्मिलित था। ये सभी भाग आपस में जुड़े हुए थे।<ref>{{cite conference|first1=Ole-Johan|last1=Dahl|first2=Kristen|last2=Nygaard|title=Class and subclass declarations|publisher=Norwegian Computing Center|conference=IFIP Working Conference on Simulation Languages|place=Oslo|date =May 1967|url=https://www.ub.uio.no/fag/naturvitenskap-teknologi/informatikk/faglig/dns/dokumenter/classandsubclass1967.pdf}}</ref> एक संयुक्त वस्तु के गुण बिंदु संकेतन द्वारा अभिगम्य होंगे। इस विचार को सबसे पहले [[Simula|सिमुला]] 67 प्रोग्रामिंग भाषा में स्वीकार किया गया था।<ref>{{cite journal |last1=Dahl |first1=Ole-Johan |title=The Birth of Object Orientation: the Simula Languages |journal=From Object-Orientation to Formal Methods |date=2004 |volume=2635 |pages=15–25 |doi=10.1007/978-3-540-39993-3_3 |url=https://www.mn.uio.no/ifi/english/about/ole-johan-dahl/bibliography/the-birth-of-object-orientation-the-simula-languages.pdf}}</ref> यह विचार तब स्मॉलटाक, [[सी ++|C ++]], [[जावा (प्रोग्रामिंग भाषा)]], [[पायथन (प्रोग्रामिंग भाषा)]], और कई अन्य भाषाओं में विस्तारित हो गया। | ||
== प्रकार == | == प्रकार == | ||
| Line 20: | Line 20: | ||
===== एकाधिक इनहेरिटेंस ===== | ===== एकाधिक इनहेरिटेंस ===== | ||
: जहाँ एक क्लास में एक से अधिक सुपरक्लास हो सकते हैं और सभी पैरेंट क्लास से सुविधाएँ प्राप्त कर सकते हैं। | : जहाँ एक क्लास में एक से अधिक सुपरक्लास हो सकते हैं और सभी पैरेंट क्लास से सुविधाएँ प्राप्त कर सकते हैं। | ||
:{{Quotation|"एकाधिक इनहेरिटेंस{{nbsp}}... व्यापक रूप से कुशलता से लागू करने के लिए बहुत | :{{Quotation|"एकाधिक इनहेरिटेंस{{nbsp}}... व्यापक रूप से कुशलता से लागू करने के लिए बहुत कठिन माना जाता था। उदाहरण के लिए, वस्तु C पर अपनी पुस्तक में C ++ के सारांश में, ब्रैड कॉक्स ने वास्तव में दावा किया था कि C ++ में एकाधिक इनहेरिटेंस जोड़ना असंभव था। इस प्रकार, एकाधिक इनहेरिटेंस एक चुनौती से अधिक लग रहा था। चूंकि मैंने 1982 की प्रारंभ में कई इनहेरिटेंस पर विचार किया था और 1984 में एक सरल और कुशल कार्यान्वयन तकनीक पाई, मैं चुनौती का विरोध नहीं कर सका। मुझे संदेह है कि यह एकमात्र स्थिति है जिसमें फैशन ने घटनाओं के अनुक्रम को प्रभावित किया<ref>{{cite book | title=The Design and Evolution of C++ |first=Bjarne |last=Stroustrup | author-link=Bjarne Stroustrup| page=417 |publisher=Pearson |date=1994 |isbn= 9780135229477}}</ref>|[[बजेर्ने स्ट्राउस्ट्रुप]]}} | ||
===== बहुस्तरीय इनहेरिटेंस ===== | ===== बहुस्तरीय इनहेरिटेंस ===== | ||
: जहां एक सबक्लास दूसरे सबक्लास से इनहेरिटेंस में मिला है। यह असामान्य नहीं है कि एक क्लास किसी अन्य व्युत्पन्न क्लास से प्राप्त होता है जैसा कि <nowiki>''बहुस्तरीय इनहेरिटेंस''</nowiki> में दिखाया गया है। | : जहां एक सबक्लास दूसरे सबक्लास से इनहेरिटेंस में मिला है। यह असामान्य नहीं है कि एक क्लास किसी अन्य व्युत्पन्न क्लास से प्राप्त होता है जैसा कि <nowiki>''बहुस्तरीय इनहेरिटेंस''</nowiki> में दिखाया गया है। | ||
:[[File:Multilevel Inheritance.jpg|thumb|right|upright|बहुस्तरीय इनहेरिटेंस]]: क्लास A व्युत्पन्न क्लास B के लिए आधार क्लास के रूप में फ़ंक्शन करता है, जो बदले में व्युत्पन्न क्लास C के लिए आधार क्लास के रूप में फ़ंक्शन करता है। क्लास B को मध्यवर्ती बेस क्लास के रूप में जाना जाता है क्योंकि यह A और C के बीच इनहेरिटेंस के लिए एक लिंक प्रदान करता है। श्रृंखला ABC को इनहेरिटेंस | :[[File:Multilevel Inheritance.jpg|thumb|right|upright|बहुस्तरीय इनहेरिटेंस]]: क्लास A व्युत्पन्न क्लास B के लिए आधार क्लास के रूप में फ़ंक्शन करता है, जो बदले में व्युत्पन्न क्लास C के लिए आधार क्लास के रूप में फ़ंक्शन करता है। क्लास B को मध्यवर्ती बेस क्लास के रूप में जाना जाता है क्योंकि यह A और C के बीच इनहेरिटेंस के लिए एक लिंक प्रदान करता है। श्रृंखला ABC को इनहेरिटेंस पथ के रूप में जाना जाता है। | ||
: बहुस्तरीय इनहेरिटेंस के साथ एक व्युत्पन्न क्लास निम्नानुसार घोषित किया गया है: | : बहुस्तरीय इनहेरिटेंस के साथ एक व्युत्पन्न क्लास निम्नानुसार घोषित किया गया है: | ||
: | : | ||
| Line 34: | Line 34: | ||
: यह वह जगह है जहां एक क्लास एक से अधिक सब-क्लास के लिए सुपरक्लास (बेस क्लास) के रूप में फ़ंक्शन करता है। उदाहरण के लिए, एक पैरेंट क्लास, A, के दो सबक्लास B और C हो सकते हैं। B और C दोनों के पैरेंट क्लास A हैं, लेकिन B और C दो अलग-अलग सबक्लास हैं। | : यह वह जगह है जहां एक क्लास एक से अधिक सब-क्लास के लिए सुपरक्लास (बेस क्लास) के रूप में फ़ंक्शन करता है। उदाहरण के लिए, एक पैरेंट क्लास, A, के दो सबक्लास B और C हो सकते हैं। B और C दोनों के पैरेंट क्लास A हैं, लेकिन B और C दो अलग-अलग सबक्लास हैं। | ||
; हाइब्रिड इनहेरिटेंस | ; हाइब्रिड इनहेरिटेंस | ||
:हाइब्रिड इनहेरिटेंस | :हाइब्रिड इनहेरिटेंस तब होता है जब उपरोक्त दो या दो से अधिक प्रकार की इनहेरिटेंस का संयोजन होता है। इसका एक उदाहरण है जब क्लास A में सबक्लास B होता है जिसमें दो सबक्लास C और डी होते हैं। यह बहुस्तरीय इनहेरिटेंस और वर्गीकृत इनहेरिटेंस दोनों का संयोजन है। | ||
== सबक्लास और सुपरक्लास == | == सबक्लास और सुपरक्लास == | ||
सबक्लास, व्युत्पन्न क्लास, उत्तराधिकारी क्लास, या बाल क्लास [[मॉड्यूलर प्रोग्रामिंग]] व्युत्पन्न क्लास हैं जो एक या एक से अधिक [[प्रोग्रामिंग भाषा]] संस्थाओं को एक या अधिक अन्य क्लास (सुपरक्लास, बेस क्लास या पैरेंट क्लास कहा जाता है) से प्राप्त करते हैं। क्लास इनहेरिटेंस | सबक्लास, व्युत्पन्न क्लास, उत्तराधिकारी क्लास, या बाल क्लास [[मॉड्यूलर प्रोग्रामिंग]] व्युत्पन्न क्लास हैं जो एक या एक से अधिक [[प्रोग्रामिंग भाषा]] संस्थाओं को एक या अधिक अन्य क्लास (सुपरक्लास, बेस क्लास या पैरेंट क्लास कहा जाता है) से प्राप्त करते हैं। क्लास इनहेरिटेंस के शब्दार्थ भाषा से भाषा में भिन्न होते हैं, लेकिन सामान्य रूप से सबक्लास स्वचालित रूप से अपने सुपरक्लास के [[उदाहरण चर]] और मेम्बर (सदस्य) फ़ंक्शन को प्राप्त करता है। | ||
व्युत्पन्न क्लास को परिभाषित करने का सामान्य रूप है:<ref>{{cite book | title=The complete reference C++ | url=https://archive.org/details/ccompletereferen00schi_178 | url-access=limited | publisher=Tata McGraw Hill |first=Herbert |last=Schildt |author-link= Herbert Schildt| year=2003 | page=[https://archive.org/details/ccompletereferen00schi_178/page/n450 417] | isbn=978-0-07-053246-5}}</ref> | व्युत्पन्न क्लास को परिभाषित करने का सामान्य रूप है:<ref>{{cite book | title=The complete reference C++ | url=https://archive.org/details/ccompletereferen00schi_178 | url-access=limited | publisher=Tata McGraw Hill |first=Herbert |last=Schildt |author-link= Herbert Schildt| year=2003 | page=[https://archive.org/details/ccompletereferen00schi_178/page/n450 417] | isbn=978-0-07-053246-5}}</ref> | ||
| Line 47: | Line 47: | ||
* कोलन इंगित करता है कि सबक्लास सुपरक्लास से इनहेरिटेंस में मिला है। दृश्यता वैकल्पिक है और, यदि सम्मिलित है, तो निजी या सार्वजनिक हो सकती है। डिफ़ॉल्ट दृश्यता निजी है। दृश्यता निर्दिष्ट करती है कि आधार क्लास की विशेषताएं निजी रूप से व्युत्पन्न हैं या सार्वजनिक रूप से व्युत्पन्न हैं। | * कोलन इंगित करता है कि सबक्लास सुपरक्लास से इनहेरिटेंस में मिला है। दृश्यता वैकल्पिक है और, यदि सम्मिलित है, तो निजी या सार्वजनिक हो सकती है। डिफ़ॉल्ट दृश्यता निजी है। दृश्यता निर्दिष्ट करती है कि आधार क्लास की विशेषताएं निजी रूप से व्युत्पन्न हैं या सार्वजनिक रूप से व्युत्पन्न हैं। | ||
कुछ भाषाएँ अन्य निर्माणों की इनहेरिटेंस का भी समर्थन करती हैं। उदाहरण के लिए, एफिल (प्रोग्रामिंग भाषा) में, डिज़ाइन द्वारा अनुबंध जो एक क्लास के विनिर्देश को परिभाषित करता है, | कुछ भाषाएँ अन्य निर्माणों की इनहेरिटेंस का भी समर्थन करती हैं। उदाहरण के लिए, एफिल (प्रोग्रामिंग भाषा) में, डिज़ाइन द्वारा अनुबंध जो एक क्लास के विनिर्देश को परिभाषित करता है, एर द्वारा भी इनहेरिटेंस में मिला है। सुपरक्लास एक सामान्य इंटरफ़ेस और मूलभूत कार्यक्षमता स्थापित करता है, जो विशेष सबक्लास इनहेरिट, संशोधित और पूरक कर सकते हैं। सबक्लास द्वारा इनहेरिटेंस में मिले सॉफ़्टवेयर को सबक्लास में पुन: प्रयोज्य माना जाता है। किसी क्लास के उदाहरण का संदर्भ वास्तव में उसके सबक्लास में से एक का संदर्भ दे सकता है। संदर्भित वस्तु का वास्तविक क्लास संकलन-समय पर भविष्यवाणी करना असंभव है। कई अलग-अलग क्लास की वस्तुओं के सदस्य फ़ंक्शन को लागू करने के लिए एक समान इंटरफ़ेस का उपयोग किया जाता है। सबक्लास सुपरक्लास फ़ंक्शन को पूरी तरह से नए फ़ंक्शन से बदल सकते हैं जो समान [[विधि हस्ताक्षर]] साझा करते हैं। | ||
=== गैर-उपवर्गीय (सबक्लासेबल) क्लास === | === गैर-उपवर्गीय (सबक्लासेबल) क्लास === | ||
कुछ भाषाओं में | कुछ भाषाओं में क्लास (कंप्यूटर प्रोग्रामिंग) गैर-सबक्लासेबल के रूप में क्लास प्रकाशन में कुछ [[वर्ग संशोधक|क्लास संशोधक]] जोड़कर घोषित किया जा सकता है। उदाहरणों में जावा और C++ 11 में <code>final</code>कीवर्ड या C # मे <code>sealed</code> कीवर्ड सम्मिलित है । इस तरह के संशोधक <code>class</code> कीवर्ड और क्लास पहचानकर्ता प्रकाशन से पहले जोड़े जाते है। ऐसे गैर-उपवर्गीय क्लास पुन: प्रयोज्यता को प्रतिबंधित करते हैं, विशेष रूप से जब विकासक के पास केवल पूर्वनिर्मित [[बाइनरी फ़ाइल]] तक अभिगम्य और स्रोत कोड नहीं होती है। | ||
एक गैर-उपवर्गीय क्लास में कोई सबक्लास नहीं होता है, इसलिए [[संकलन समय]] पर यह आसानी से निकाला जा सकता है कि उस क्लास की वस्तुओं के संदर्भ या संकेत वास्तव में उस क्लास के उदाहरणों को संदर्भित कर रहे हैं और सबक्लास के उदाहरण नहीं हैं (वे सम्मिलित नहीं हैं) या सुपरक्लास के उदाहरण (संदर्भ प्रकार को [[upcasting|अपकास्ट]] करना प्रारूप प्रणाली का उल्लंघन करता है)। चूंकि संदर्भित वस्तु का परिशुद्ध प्रारूप निष्पादन से पहले जाना जाता है, प्रारंभिक बाध्यकारी (स्थिर प्रेषण भी कहा जाता है) का उपयोग देर से बाइंडिंग (जिसे [[गतिशील प्रेषण]] भी कहा जाता है) के अतिरिक्त किया जा सकता है, जिसके लिए एकाधिक इनहेरिटेंस के आधार पर एक या अधिक वर्चुअल विधि सारणी जाँचने की आवश्यकता होती है या उपयोग की जा रही प्रोग्रामिंग भाषा में केवल एक इनहेरिटेंस | एक गैर-उपवर्गीय क्लास में कोई सबक्लास नहीं होता है, इसलिए [[संकलन समय]] पर यह आसानी से निकाला जा सकता है कि उस क्लास की वस्तुओं के संदर्भ या संकेत वास्तव में उस क्लास के उदाहरणों को संदर्भित कर रहे हैं और सबक्लास के उदाहरण नहीं हैं (वे सम्मिलित नहीं हैं) या सुपरक्लास के उदाहरण (संदर्भ प्रकार को [[upcasting|अपकास्ट]] करना प्रारूप प्रणाली का उल्लंघन करता है)। चूंकि संदर्भित वस्तु का परिशुद्ध प्रारूप निष्पादन से पहले जाना जाता है, प्रारंभिक बाध्यकारी (स्थिर प्रेषण भी कहा जाता है) का उपयोग देर से बाइंडिंग (जिसे [[गतिशील प्रेषण]] भी कहा जाता है) के अतिरिक्त किया जा सकता है, जिसके लिए एकाधिक इनहेरिटेंस के आधार पर एक या अधिक वर्चुअल विधि सारणी जाँचने की आवश्यकता होती है या उपयोग की जा रही प्रोग्रामिंग भाषा में केवल एक इनहेरिटेंस का समर्थन किया जाता है। | ||
=== गैर-अतिव्यापी (ओवर्रिजेबल)तरीके === | === गैर-अतिव्यापी (ओवर्रिजेबल)तरीके === | ||
जैसे क्लास गैर-उपवर्गीय हो सकती हैं, विधि प्रकाशन में विधि संशोधक हो सकते हैं जो विधि को ओवरराइड होने से रोकते हैं (अर्थात एक ही नाम के साथ एक नए फ़ंक्शन के साथ प्रतिस्थापित किया जाता है और सबक्लास में प्रारूप संकेत करता है)। निजी विधि गैर-ओवर्रिजेबल है क्योंकि यह क्लास के अतिरिक्त अन्य क्लास | जैसे क्लास गैर-उपवर्गीय हो सकती हैं, विधि प्रकाशन में विधि संशोधक हो सकते हैं जो विधि को ओवरराइड होने से रोकते हैं (अर्थात एक ही नाम के साथ एक नए फ़ंक्शन के साथ प्रतिस्थापित किया जाता है और सबक्लास में प्रारूप संकेत करता है)। निजी विधि गैर-ओवर्रिजेबल है क्योंकि यह क्लास के अतिरिक्त अन्य क्लास द्वारा अभिगम्य योग्य नहीं है, यह मेम्बर फ़ंक्शन है (हालांकि यह C ++ के लिए सत्य नहीं है )। जावा में <code>final</code> विधि, C # में <code>sealed</code>विधि या एफिल में <code>frozen</code> सुविधा को ओवरराइड नहीं किया जा सकता है। | ||
=== आभासी तरीके === | === आभासी तरीके === | ||
| Line 98: | Line 98: | ||
=== ओवरराइडिंग === | === ओवरराइडिंग === | ||
{{Main|ओवरराइडिंग विधि}} | {{Main|ओवरराइडिंग विधि}} | ||
[[File:Method overriding in subclass.svg|thumb|विधि ओवरराइडिंग का चित्रण]]कई वस्तु उन्मुख | [[File:Method overriding in subclass.svg|thumb|विधि ओवरराइडिंग का चित्रण]]कई वस्तु उन्मुख प्रोग्रामिंग भाषा एक क्लास या ऑब्जेक्ट (वस्तु) को एक स्वरूप के कार्यान्वयन को बदलने की अनुमति देती हैं - सामान्य रूप से एक गतिविधि - जो इसे इनहेरिटेंस में प्राप्त हुई है। इस प्रक्रिया को ओवरराइडिंग कहा जाता है। ओवरराइडिंग एक जटिलता का परिचय देती है: गतिविधि का कौन सा संस्करण इनहेरिटेंस में संयोजित क्लास का उपयोग करता है - वह जो अपनी क्लास का हिस्सा है, या पैरेंट (बेस) क्लास से एक है? उत्तर प्रोग्रामिंग भाषाओं के बीच भिन्न होता है, और कुछ भाषाएं यह इंगित करने की क्षमता प्रदान करती हैं कि एक विशेष गतिविधि को ओवरराइड नहीं किया जाना चाहिए और बेस क्लास द्वारा परिभाषित गतिविधि करना चाहिए। उदाहरण के लिए, C # में, वेस विधि या गुण को सब-क्लास में केवल तभी ओवरराइड किया जा सकता है यदि इसे आभासी, अमूर्त, या ओवरराइड संशोधक के साथ चिह्नित किया गया हो, जबकि जावा जैसी प्रोग्रामिंग भाषाओं में, अन्य विधियों को ओवरराइड करने के लिए विभिन्न विधियों को कहा जा सकता है।<ref>[http://msdn.microsoft.com/en-us/library/ebca9ah3.aspx override(C# Reference)]</ref> ओवरराइडिंग का एक विकल्प इनहेरिटेंस में प्राप्त कोड को [[छिपाना (प्रोग्रामिंग)]] है। | ||
=== [[कोड पुन: उपयोग]] === | === [[कोड पुन: उपयोग|कोड का पुन: उपयोग]] === | ||
इंप्लीमेंटेशन इनहेरिटेंस वह तंत्र है जिसके द्वारा एक सबक्लास कोड का पुन: उपयोग करता है | एक आधार क्लास में कोड का पुन: उपयोग करता है। डिफ़ॉल्ट रूप से सबक्लास आधार क्लास के सभी फ़ंक्शन को बनाए रखता है, लेकिन सबक्लास कुछ या सभी फ़ंक्शन को ओवरराइड कर सकता है, आधार क्लास के कार्यान्वयन को अपने आप से बदल सकता है। | इंप्लीमेंटेशन इनहेरिटेंस वह तंत्र है जिसके द्वारा एक सबक्लास कोड का पुन: उपयोग करता है | एक आधार क्लास में कोड का पुन: उपयोग करता है। डिफ़ॉल्ट रूप से सबक्लास आधार क्लास के सभी फ़ंक्शन को बनाए रखता है, लेकिन सबक्लास कुछ या सभी फ़ंक्शन को ओवरराइड कर सकता है, आधार क्लास के कार्यान्वयन को अपने आप से बदल सकता है। | ||
निम्नलिखित पायथन उदाहरण में, सबक्लास {{mono|SquareSumComputer}} और {{mono|CubeSumComputer}} बेस क्लास | निम्नलिखित पायथन उदाहरण में, सबक्लास {{mono|SquareSumComputer}} और {{mono|CubeSumComputer}} बेस क्लास {{mono|transform()}} के {{mono|SumComputer}} विधि को ओवरराइड करते है। बेस क्लास में दो पूर्णांकों के बीच [[वर्ग संख्या|क्लास संख्या]] के योग की गणना करने के लिए संचालन सम्मिलित हैं। सबक्लास बेस क्लास की सभी कार्यक्षमताओं का पुन: उपयोग करता है, संचालन के आक्षेप के साथ जो किसी संख्या को उसके क्लास में बदल देता है, इसे एक ऐसे संचालन से बदल देता है जो एक संख्या को क्रमशः उसके क्लास और घन में बदल देता है। सबक्लास इसलिए दो पूर्णांकों के बीच वर्गों/घनों के योग की गणना करते हैं। | ||
नीचे पायथन का एक उदाहरण है। | नीचे पायथन का एक उदाहरण है। | ||
| Line 130: | Line 130: | ||
अधिकांश | अधिकांश क्वार्टर में, कोड पुन: उपयोग के एकमात्र उद्देश्य के लिए क्लास इनहेरिटेंस पक्ष से बाहर हो गई है।{{Citation needed|date=November 2009}} प्राथमिक स्थिति यह है कि कार्यान्वयन इनहेरिटेंस वस्तु-उन्मुख प्रोग्रामिंग प्रतिस्थापन क्षमता में बहुरूपता का कोई दृढ़ प्रमाण प्रदान नहीं करता है - पुन: उपयोग करने वाले क्लास का एक उदाहरण इनहेरिटेंस में मिले क्लास के उदाहरण के लिए आवश्यक रूप से प्रतिस्थापित नहीं किया जा सकता है। एक वैकल्पिक तकनीक, स्पष्ट [[प्रतिनिधिमंडल पैटर्न|प्रत्यायोजन पैटर्न]] के लिए अधिक प्रोग्रामिंग प्रयास की आवश्यकता होती है, लेकिन प्रतिस्थापनीयता के विषय से बचा जाता है।{{Citation needed|date=May 2012}} C ++ में निजी इनहेरिटेंस को प्रतिस्थापन योग्यता के बिना कार्यान्वयन इनहेरिटेंस के रूप में उपयोग किया जा सकता है। जबकि सार्वजनिक इनहेरिटेंस एक संबंध का प्रतिनिधित्व करती है और प्रत्यायोजन एक संबंध का प्रतिनिधित्व करता है, निजी (और संरक्षित) इनहेरिटेंस को संबंध के संदर्भ में लागू किया जा सकता है।<ref>{{cite web|url=http://www.gotw.ca/gotw/060.htm |title=GotW #60: Exception-Safe Class Design, Part 2: Inheritance |publisher=Gotw.ca |access-date=2012-08-15}}</ref> | ||
इनहेरिटेंस का अन्य निरंतर उपयोग यह गारंटी देना है कि क्लास एक निश्चित सामान्य इंटरफ़ेस बनाए रखती हैं; अर्थात्, वे समान विधियों को लागू करते हैं। पैरेंट क्लास कार्यान्वित संचालन और संचालन का एक संयोजन हो सकता है जिसे चाइल्ड क्लास में लागू किया जाना है। प्रायः, सुपरटाइप और सबटाइपिंग के बीच कोई इंटरफ़ेस परिवर्तन नहीं होता है- चाइल्ड अपने पैरेंट क्लास के अतिरिक्त वर्णित गतिविधि को लागू करता है।<ref>{{cite book | title=Mastering C++ | publisher=Tata McGraw Hill Education Private Limited |first=K.R. |last=Venugopal |first2=Rajkumar |last2=Buyya | year=2013 | page=609 | isbn=9781259029943}}</ref> | |||
== इनहेरिटेंस | |||
{{further| | |||
इनहेरिटेंस | == इनहेरिटेंस बनाम सबटाइपिंग == | ||
{{further|सबटाइपिंग}} | |||
इनहेरिटेंस समान है लेकिन सबटाइपिंग से अलग है।<ref name=Cook90/>सबटाइपिंग किसी दिए गए प्रकार को दूसरे प्रकार या अमूर्त के लिए प्रतिस्थापित करने में सक्षम बनाता है, और कहा जाता है कि सबटाइपिंग और कुछ सम्मिलित अमूर्तता के बीच संबंध स्थापित करने के लिए या तो अंतर्निहित या स्पष्ट रूप से भाषा समर्थन पर निर्भर करता है। संबंध को उन भाषाओं में इनहेरिटेंस के माध्यम से स्पष्ट रूप से व्यक्त किया जा सकता है जो सबटाइपिंग तंत्र के रूप में इनहेरिटेंस का समर्थन करते हैं। उदाहरण के लिए, निम्नलिखित C ++ कोड क्लास B और A के बीच एक स्पष्ट इनहेरिटेंस संबंध स्थापित करता है, जहां B A के उप-क्लास और सबटाइपिंग दोनों है, और A के रूप में इस्तेमाल किया जा सकता है जहां B निर्दिष्ट किया गया है (एक संदर्भ, एक सूचक या स्वयं वस्तु के माध्यम से)। | |||
class A { | class A { | ||
| Line 158: | Line 161: | ||
} | } | ||
प्रोग्रामिंग भाषाओं में जो एक [[उपप्रकार बहुरूपता|सबटाइपिंग बहुरूपता]] के रूप में इनहेरिटेंस का समर्थन नहीं करते हैं, [[डेटा प्रकार]] के बीच संबंध की तुलना में आधार क्लास और व्युत्पन्न क्लास के बीच संबंध केवल कार्यान्वयन (कोड पुन: उपयोग के लिए एक तंत्र) के बीच संबंध है। इनहेरिटेंस , यहां तक कि प्रोग्रामिंग भाषाओं में भी जो एक सबटाइपिंग तंत्र के रूप में इनहेरिटेंस का समर्थन करते हैं, आवश्यक रूप से व्यवहारिक सबटाइपिंग की आवश्यकता नहीं है। एक क्लास को प्राप्त करना पूरी तरह से संभव है जिसका वस्तु गलत तरीके से गतिविधि करेगा जब उस संदर्भ में उपयोग किया जाता है जहां पैरेंट क्लास की अपेक्षा की जाती है; [[लिस्कोव प्रतिस्थापन सिद्धांत]] देखें।<ref name="Mitchell2002"> | |||
प्रोग्रामिंग भाषाओं में जो एक [[उपप्रकार बहुरूपता|सबटाइपिंग बहुरूपता]] के रूप में इनहेरिटेंस | |||
<ref name="Mitchell2002"> | |||
{{cite book | {{cite book | ||
| last=Mitchell | | last=Mitchell | ||
| Line 173: | Line 174: | ||
| page=[https://archive.org/details/conceptsprogramm00mitc/page/n298 287] | | page=[https://archive.org/details/conceptsprogramm00mitc/page/n298 287] | ||
| chapter=10 "Concepts in object-oriented languages"}} | | chapter=10 "Concepts in object-oriented languages"}} | ||
</ref> ( | </ref> (अर्थ/निरूपण की तुलना करें।) कुछ वस्तु उन्मुख प्रोग्रामिंग भाषाओं में, कोड पुन: उपयोग और उपप्रकार की धारणा मेल खाती है क्योंकि सबटाइपिंग घोषित करने का एकमात्र तरीका एक नए क्लास को परिभाषित करना है जो दूसरे के कार्यान्वयन को प्राप्त करता है। | ||
=== डिजाइन की कमी === | === डिजाइन की कमी === | ||
किसी प्रोग्राम को डिजाइन करने में इनहेरिटेंस का बड़े पैमाने पर उपयोग करने से कुछ बाधाएँ आती हैं। | |||
उदाहरण के लिए, एक क्लास {{mono|Person}} पर विचार करें जिसमें एक व्यक्ति का नाम, जन्म तिथि, पता और फोन नंबर सम्मिलित हो। हम {{mono|Student}} नामक {{mono|Person}} सबक्लास को परिभाषित कर सकते हैं जिसमें व्यक्ति का ग्रेड बिंदु औसत और ली गई क्लास सम्मिलित है, और {{mono|Employee}} नामक {{mono|Person}} का एक अन्य उपवर्ग जिसमें व्यक्ति का कार्य-शीर्षक, नियोक्ता और वेतन सम्मिलित है। | |||
इस इनहेरिटेंस पदानुक्रम को परिभाषित करने में हमने पहले ही कुछ प्रतिबंधों को परिभाषित कर दिया है, जिनमें से सभी वांछनीय नहीं हैं: | |||
उदाहरण | ;एकनिष्ठता: एकल इनहेरिटेंस का उपयोग करके, एक सबक्लास केवल एक सुपरक्लास से इनहेरिट कर सकता है। ऊपर दिए गए उदाहरण को जारी रखते हुए, एक {{mono|Person}} वस्तु या {{mono|Student}} या एक {{mono|Employee}} हो सकता है, लेकिन दोनों नहीं। एकाधिक इनहेरिटेंस का उपयोग आंशिक रूप से इस समस्या को हल करता है, क्योंकि इसके बाद एक {{mono|StudentEmployee}} को परिभाषित किया जा सकता है जो {{mono|Student}} और {{mono|Employee}} दोनों से प्राप्त होता है। हालांकि, अधिकांश कार्यान्वयनों में, यह अभी भी प्रत्येक सुपरक्लास से केवल एक बार इनहेरिट कर सकता है, और इस प्रकार, उन स्थितियों का समर्थन नहीं करता है जिनमें एक छात्र के पास दो नौकरियां हैं या दो संस्थानों में भाग लेता है। एफिल में उपलब्ध इनहेरिटेंस मॉडल बार-बार इनहेरिटेंस के समर्थन के माध्यम से इसे संभव बनाता है। | ||
==== स्थिर: ==== | |||
जब वस्तु का प्रकार चयन किया जाता है और समय के साथ नहीं बदलता है, तो किसी वस्तु का इनहेरिटेंस पदानुक्रम तात्कालिकता पर तय हो जाता है। उदाहरण के लिए, इनहेरिटेंस ग्राफ अपने {{mono|Person}} सुपरक्लास की स्थिति को बनाए रखते हुए एक {{mono|Student}} बनने की वस्तु {{mono|Employee}} वस्तु बनने की अनुमति नहीं देता है। (इस तरह का गतिविधि, हालांकि, निर्वाहक स्वरूप के साथ प्राप्त किया जा सकता है।) कुछ ने इनहेरिटेंस की आलोचना की है, यह तर्क देते हुए कि यह विकासक को उनके मूल डिजाइन मानकों में बंद कर देता है।{{r|holub}} | |||
==== दृश्यता: ==== | |||
जब भी क्लाइंट कोड की किसी वस्तु तक अभिगम्य होती है, तो सामान्य रूप से वस्तु के सभी सुपरक्लास डेटा तक उसकी अभिगम्य होती है। यहां तक कि यदि सुपरक्लास को सार्वजनिक घोषित नहीं किया गया है, तो क्लाइंट अभी भी [[टाइपकास्ट (प्रोग्रामिंग)]] ऑब्जेक्ट को अपने सुपरक्लास प्रकार में कर सकता है। उदाहरण के लिए, {{mono|Student}} के {{mono|Person}} सुपरक्लास में संग्रहीत सभी व्यक्तिगत डेटा तक उस फ़ंक्शन को अभिगम्य प्रदान किए बिना किसी छात्र के ग्रेड बिंदु औसत और प्रतिलेख के लिए फ़ंक्शन को पॉइंटर देने का कोई तरीका नहीं है। C ++ और जावा समेत कई आधुनिक भाषाएं, एक "संरक्षित" अभिगम्य संशोधक प्रदान करती हैं जो सबक्लास को डेटा तक अभिगम्य की अनुमति देती है, बिना किसी कोड को इनहेरिटेंस की श्रृंखला के बाहर पहुंचने की अनुमति देता है। | |||
[[समग्र पुन: उपयोग सिद्धांत]] इनहेरिटेंस | [[समग्र पुन: उपयोग सिद्धांत]] इनहेरिटेंस का एक विकल्प है। यह तकनीक प्राथमिक क्लास पदानुक्रम से गतिविधि को अलग करके और किसी व्यावसायिक डोमेन क्लास में आवश्यक विशिष्ट गतिविधि क्लास सहित बहुरूपता और कोड पुन: उपयोग का समर्थन करती है। यह दृष्टिकोण रन टाइम पर गतिविधि संशोधनों की स्वीकृति देकर एक क्लास पदानुक्रम की स्थिर स्वरूप से बचता है और एक क्लास को अपने अग्रगामी क्लास के गतिविधि तक सीमित होने के अतिरिक्त बुफे-शैली के गतिविधि को लागू करने की स्वीकृति देता है। | ||
== मुद्दे और विकल्प == | == मुद्दे और विकल्प == | ||
कार्यान्वयन इनहेरिटेंस | कार्यान्वयन इनहेरिटेंस कम से कम 1990 के दशक से प्रोग्रामरों और वस्तु उन्मुख प्रोग्रामिंग के सिद्धांतकारों के बीच विवादास्पद रहा है। उनमें से डिज़ाइन पैटर्न के लेखक हैं, जो इसके अतिरिक्त इंटरफ़ेस इनहेरिटेंस का समर्थन करते हैं, और इनहेरिटेंस पर रचना का पक्ष लेते हैं। उदाहरण के लिए, क्लास के बीच इनहेरिटेंस की स्थिर प्रकृति को दूर करने के लिए निर्वाहक पैटर्न (जैसा ऊपर बताया गया है) प्रस्तावित किया गया है। एक ही समस्या के अधिक मौलिक समाधान के रूप में, भूमिका-उन्मुख प्रोग्रामिंग एक नई अवधारणा में इनहेरिटेंस और रचना के गुणों के संयोजन से, एक अलग संबंध का परिचय देती है।{{citation needed|date=February 2016}} | ||
एलन होलूब के अनुसार, | |||
कथित रूप से, जावा के आविष्कारक [[जेम्स गोस्लिंग]] ने कार्यान्वयन इनहेरिटेंस के | एलन होलूब के अनुसार, कार्यान्वयन इनहेरिटेंस के साथ मुख्य समस्या यह है कि यह "फ्रैजल बेस क्लास समस्या" के रूप में अनावश्यक युग्मन का परिचय देता है:{{r|Mikhajlov}} बेस क्लास के कार्यान्वयन में संशोधन सबक्लास में असावधान गतिविधि परिवर्तन का कारण बन सकता है। इंटरफेस का उपयोग करने से इस समस्या से बचा जाता है क्योंकि केवल एप्लीकेशन प्रोग्रामिंग इंटरफेस को कोई कार्यान्वयन साझा नहीं किया जाता है{{r|holub}} इसे बताने का एक और तरीका यह है कि इनहेरिटेंस ब्रेक [[एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)|कैप्सुलन ((वस्तु-उन्मुख प्रोग्रामिंग) )]] है।<ref>{{Cite journal | doi = 10.1145/250707.239108| title = Evolution of object behavior using context relations| journal = ACM SIGSOFT Software Engineering Notes| volume = 21| issue = 6| page = 46| year = 1996| last1 = Seiter | first1 = Linda M.| last2 = Palsberg | first2 = Jens| last3 = Lieberherr | first3 = Karl J.| url = http://www.ccs.neu.edu/research/demeter/papers/context-journal/_context.html| citeseerx = 10.1.1.36.5053}}</ref> समस्या खुले वस्तु-उन्मुख प्रणाली जैसे [[सॉफ्टवेयर ढांचा|सॉफ्टवेयर]] रूपरेखा में स्पष्ट रूप से सामने आती है, जहाँ क्लाइंट कोड को प्रणाली-आपूर्ति वाली क्लास से इनहेरिटेंस में मिलने की अपेक्षा की जाती है और फिर इसके एल्गोरिदम में प्रणाली की क्लास के लिए प्रतिस्थापित किया जाता है।{{r|Mikhajlov}} | ||
कथित रूप से, जावा के आविष्कारक [[जेम्स गोस्लिंग]] ने कार्यान्वयन इनहेरिटेंस के विपरीत बात की है, यह कहते हुए कि यदि वह जावा को फिर से डिज़ाइन करना चाहते हैं तो वह इसे सम्मिलित नहीं करेंगे।<ref name="holub">{{cite web |first=Allen |last=Holub |author-link=Allen Holub |url=http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html |title=Why extends is evil |date=1 August 2003 |access-date=10 March 2015}}</ref> भाषा डिजाइन जो सबटाइपिंग (इंटरफ़ेस इनहेरिटेंस ) से इनहेरिटेंस को कम करते हैं, 1990 के प्रारंभ में दिखाई दिए;<ref>{{Cite conference| doi = 10.1007/BFb0019440| title = Designing an object-oriented programming language with behavioural subtyping| conference = REX School/Workshop on the Foundations of Object-Oriented Languages| volume = 489| pages = 60–90| series = Lecture Notes in Computer Science| year = 1991| last1 = America | first1 = Pierre| isbn = 978-3-540-53931-5| url = https://www.researchgate.net/publication/221501695}}</ref> इसका एक आधुनिक उदाहरण गो प्रोग्रामिंग भाषा है। | |||
जटिल इनहेरिटेंस , या अपर्याप्त रूप से परिपक्व डिजाइन के | जटिल इनहेरिटेंस , या अपर्याप्त रूप से परिपक्व डिजाइन के अंदर उपयोग की जाने वाली इनहेरिटेंस, [[यो-यो समस्या]] का कारण बन सकती है। 1990 के दशक के अंत में जब इनहेरिटेंस का उपयोग संरचना प्रोग्राम के प्राथमिक दृष्टिकोण के रूप में किया गया था, तो विकासक ने कोड को इनहेरिटेंस की अधिक स्तरों में विभाजित करने का प्रयास किया क्योंकि प्रणाली की कार्यक्षमता बढ़ गई थी। यदि एक विकास समूह ने एकल दायित्व सिद्धांत के साथ इनहेरिटेंस की कई स्तरों को संयोजित किया, तो इसके परिणामस्वरूप कोड की बहुत पतली परतें बन गईं, जिसमें वास्तविक कोड की केवल 1 या 2 पंक्तियों वाली कई परतें थीं।{{Citation needed|date=October 2022}} बहुत सारी परतें डिबगिंग को एक महत्वपूर्ण चुनौती बनाती हैं, क्योंकि यह निर्धारित करना कठिन हो जाता है कि किस परत को डीबग करने की आवश्यकता है। | ||
इनहेरिटेंस | इनहेरिटेंस के साथ एक और समस्या यह है कि सबक्लास को कोड में परिभाषित किया जाना चाहिए, जिसका अर्थ है कि प्रोग्राम उपयोगकर्ता रनटाइम पर नए सबक्लास नहीं जोड़ सकते। अन्य डिजाइन पैटर्न (जैसे इकाई-घटक-प्रणाली) प्रोग्राम के उपयोगकर्ताओं को रनटाइम पर एक इकाई की विविधताओं को परिभाषित करने की स्वीकृति देते हैं। | ||
== यह भी देखें == | == यह भी देखें == | ||
Revision as of 15:56, 19 February 2023
वस्तु-उन्मुख प्रोग्रामिंग में, इनहेरिटेंस एक वस्तु या क्लास को किसी अन्य वस्तु (प्रोटोटाइप-आधारित इनहेरिटेंस) या क्लास (क्लास-बेस्ड इनहेरिटेंस) पर आधारित करने का तंत्र है, समान कार्यान्वयन को बनाए रखता है। सुपर क्लास या बेस क्लास जैसे सम्मिलित क्लास से नई क्लास (सब-क्लास) प्राप्त करने और फिर उन्हें क्लास के पदानुक्रम में बनाने के रूप में भी परिभाषित किया गया है। अधिकांश क्लास-आधारित वस्तु-उन्मुख भाषाओं में, इनहेरिटेंस के माध्यम से बनाई गई एक वस्तु, एक "चाइल्ड ऑब्जेक्ट", निर्माणकर्ता डिस्ट्रक्टर, अतिभारित संचालक और बेस क्लास के फ्रेंड फंक्शन के आक्षेप के साथ "पैरेंट ऑब्जेक्ट" के सभी गुणों और गतिविधि को प्राप्त करती है। इनहेरिटेंस प्रोग्रामर को सम्मिलित क्लास पर निर्मित क्लास बनाने की स्वीकृति देता है,[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
};
- कोलन इंगित करता है कि सबक्लास सुपरक्लास से इनहेरिटेंस में मिला है। दृश्यता वैकल्पिक है और, यदि सम्मिलित है, तो निजी या सार्वजनिक हो सकती है। डिफ़ॉल्ट दृश्यता निजी है। दृश्यता निर्दिष्ट करती है कि आधार क्लास की विशेषताएं निजी रूप से व्युत्पन्न हैं या सार्वजनिक रूप से व्युत्पन्न हैं।
कुछ भाषाएँ अन्य निर्माणों की इनहेरिटेंस का भी समर्थन करती हैं। उदाहरण के लिए, एफिल (प्रोग्रामिंग भाषा) में, डिज़ाइन द्वारा अनुबंध जो एक क्लास के विनिर्देश को परिभाषित करता है, एर द्वारा भी इनहेरिटेंस में मिला है। सुपरक्लास एक सामान्य इंटरफ़ेस और मूलभूत कार्यक्षमता स्थापित करता है, जो विशेष सबक्लास इनहेरिट, संशोधित और पूरक कर सकते हैं। सबक्लास द्वारा इनहेरिटेंस में मिले सॉफ़्टवेयर को सबक्लास में पुन: प्रयोज्य माना जाता है। किसी क्लास के उदाहरण का संदर्भ वास्तव में उसके सबक्लास में से एक का संदर्भ दे सकता है। संदर्भित वस्तु का वास्तविक क्लास संकलन-समय पर भविष्यवाणी करना असंभव है। कई अलग-अलग क्लास की वस्तुओं के सदस्य फ़ंक्शन को लागू करने के लिए एक समान इंटरफ़ेस का उपयोग किया जाता है। सबक्लास सुपरक्लास फ़ंक्शन को पूरी तरह से नए फ़ंक्शन से बदल सकते हैं जो समान विधि हस्ताक्षर साझा करते हैं।
गैर-उपवर्गीय (सबक्लासेबल) क्लास
कुछ भाषाओं में क्लास (कंप्यूटर प्रोग्रामिंग) गैर-सबक्लासेबल के रूप में क्लास प्रकाशन में कुछ क्लास संशोधक जोड़कर घोषित किया जा सकता है। उदाहरणों में जावा और 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 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 पर विचार करें जिसमें एक व्यक्ति का नाम, जन्म तिथि, पता और फोन नंबर सम्मिलित हो। हम 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.
- ↑ 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.
