वंशानुक्रम (कंप्यूटर विज्ञान)
ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग (OOP) में वंशानुक्रम, पहले से परिभाषित वर्गों के प्रयोग द्वारा नए क्लास तैयार करने का एक तरीक़ा है (जिसके उदाहरण ऑब्जेक्ट कहलाते हैं). वंशानुक्रम को मौजूदा कोड में थोड़े या बिना संशोधन के पुनः प्रयोग के लिए उपयोग में लाया जाता है। नए वर्ग, जो सब-क्लास (या व्युत्पन्न वर्ग) के रूप में जाने जाते हैं, पूर्व-प्रचलित वर्गों के गुण और व्यवहार विरासत में पाते हैं, जो सुपर-क्लास (या पूर्वज वर्ग) के रूप में निर्दिष्ट किए जाते हैं। सब और सुपर-क्लास का वंशानुक्रम रिश्ता पदानुक्रम को जन्म देता है। सिमुला के लिए 1967 में वंशानुक्रम की अवधारणा का आविष्कार किया गया था।
वंशानुक्रम को (उप-प्रकार) बहुरूपता के साथ भ्रमित नहीं किया जाना चाहिए, जिसे सामान्यतः ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में पॉलीमॉर्फ़िस्म कहा जाता है। वंशानुक्रम कार्यान्वयनों के बीच रिश्ता है, जबकि उप-प्रकार बहुरूपता (पॉलिमॉर्फ़िस्म) प्रकारों (OOP में अंतराफलक) के बीच संबंध है। (लक्ष्यार्थ/वाच्यार्थ की तुलना करें.) कुछ में, लेकिन सभी OOP भाषाओं में नहीं, उद्देश्य मेल खाते हैं क्योंकि उप-प्रकार घोषित करने का एकमात्र तरीका, एक नए वर्ग को परिभाषित करना है जो किसी अन्य के कार्यान्वयन को विरासत में पाता है। वंशानुक्रम के लिए व्यवहार उप-प्रकार कभी आवश्यक नहीं है। क्लास (वर्ग) को प्राप्त करना पूरी तरह संभव है, जिसका ऑब्जेक्ट ग़लत व्यवहार करेगा जब उसका इस्तेमाल ऐसे संदर्भ में हो, जहां जनक वर्ग (पेरेंट क्लास) प्रत्याशित हो; लिसकोव प्रतिस्थापन सिद्धांत देखें.
जटिल वंशानुक्रम, या एक अपर्याप्त परिपक्व डिजाइन में इस्तेमाल किए गए वंशानुक्रम से यो-यो समस्या पैदा हो सकती है।
वंशानुक्रम का उपयोग कई लाभ प्रदान करता है। कभी-कभी इन स्पंदों में अंतर वांछनीय है, क्योंकि ज़रूरी नहीं कि ये संदर्भ से स्पष्ट हों.["जॉन क्रिश्चियन ए. गुरो]"
कई ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाएं एक वर्ग या ऑब्जेक्ट को किसी पहलू के कार्यान्वयन-आम तौर पर व्यवहार- को प्रतिस्थापित करने की अनुमति देते हैं, जो उसे विरासत में मिला है। इस प्रक्रिया को सामान्यतः "अधिभावी" (ओवरराइडिंग) कहा जाता है। अधिभावी एक जटिलता प्रवेश कराता है: व्यवहार का कौन-सा संस्करण निहित वर्ग प्रयोग का आग्रह करता है-वह जो अपने ही वर्ग का हिस्सा है, या वह जो जनक (आधार) वर्ग से है? प्रोग्रामिंग भाषाओं के बीच उत्तर भिन्न होता है और कुछ भाषाएं उसे यह सूचित करने की क्षमता प्रदान करते हैं कि किसी विशिष्ट व्यवहार को अधिरोहित और व्यवहृत नहीं किया जाए.
किसी अन्य वर्ग में पहले से ही मौजूद कोड का दुबारा उपयोग, वंशानुक्रम का उपयोग करने के प्रारंभिक प्रयोजनों में से एक रहा है। इस अभ्यास को आम तौर पर वंशानुक्रम कार्यान्वयन कहा जाता है।
अधिकांश क्षेत्रों में, कोड के पुनः प्रयोग के एकमात्र उद्देश्य के लिए वर्ग वंशानुक्रम के समर्थन में कमी आई है। प्राथमिक चिंता यह है कि कार्यान्वयन वंशानुक्रम बहुरूपी प्रतिस्थापन-क्षमता का कोई आश्वासन प्रदान नहीं करती-वर्ग का पुनः उपयोग ज़रूरी नहीं कि निहित वर्ग के उदाहरण से प्रतिस्थापित हो. एक वैकल्पिक तकनीक, प्रत्यायोजन के लिए और प्रोग्रामिंग प्रयास की आवश्यकता है, लेकिन प्रतिस्थापन-क्षमता के मुद्दे का परिहार हो जाता है। C + + में निजी वंशानुक्रम को बिना प्रतिस्थापन-क्षमता के ही "कार्यान्वयन वंशानुक्रम" के रूप में प्रयोग किया जा सकता है। जहां पब्लिक वंशानुक्रम प्रतिनिधित्व करता है रिश्ता "है" का और प्रत्यायोजन प्रतिनिधित्व करता है रिश्ता "मौजूद है" का, तो निजी (और संरक्षित) वंशानुक्रम पर रिश्ते "के कार्यान्वयन के संदर्भ में" विचार किया जा सकता है।
ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग लैंग्वेज ईफ़ल के निर्माता बर्ट्रेंड मेयेर द्वारा लिखित "ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर कंस्ट्रक्शन, द्वितीय संस्करण" में वंशानुक्रम के 12 अलग उपयोगों को सूचीबद्ध किया गया है, जहां अधिकांश में वंशानुक्रम कार्यान्वयन की कुछ मात्रा शामिल है।
बहुरूपताओं के कई प्रकार मौजूद हैं (भाषा की प्रकार-प्रणाली में). उदाहरण के लिए,
- टेम्पलेट्स (जिनेरिक), - सदस्य/ऑपरेटर अतिभार, - अवपीड़न और - उप-प्रकार बहुरूपता.
जब कोई ऑब्जेक्ट ओरिएंटेशन के साथ बहुरूपता की बात करता है, तो तात्पर्य अक्सर उप-प्रकार बहुरूपता से है। सिद्धांततः उप-प्रकार बहुरूपता का मतलब है कि ऑब्जेक्ट कई प्रकार के हो सकते हैं। जैसे
क्लास B: पब्लिक A {};
B ऑब्जेक्ट केवल B ऑब्जेक्ट नहीं हैं, वे A ऑब्जेक्ट भी हैं। यह वंशानुक्रम के माध्यम से हासिल हुआ है।
अब आप भी कर सकते हैं,
क्लास C : पब्लिक {};
और उप-प्रकार बहुरूपता की वजह से C ऑब्जेक्ट, A ऑब्जेक्ट भी हैं।
अब स्थिति यह है कि दोनों, C और B ऑब्जेक्ट, A ऑब्जेक्ट भी होने की वजह से उन दोनों को A प्रकार के वेरिएबल भी निर्दिष्ट किए जा सकते हैं। उप-प्रकार बहुरूपता यही निष्पादित करता है। लेकिन यह बिलकुल व्यर्थ होगा, अगर B और C ऑब्जेक्ट एकसमान हों तो. अच्छी बात है यह है कि उनका ऐसा होना ज़रूरी नहीं, क्योंकि अधिभावी की वजह से उनके व्यवहार में अंतर लाया जा सकता है।
अतः उप-प्रकार बहुरूपता के पीछे प्रमुख भाषा तंत्र वंशानुक्रम है (एक वस्तु के कई प्रकार हो सकते हैं). अधिभावी की भूमिका है उप-प्रकार ऑब्जेक्ट द्वारा एक आम सुपर-प्रकार साझा करने को अनुमत करना, ताकि उनका व्यवहार अलग हो.
जब प्रोग्राम को डिज़ाइन करते समय वंशानुक्रम का व्यापक रूप से उपयोग किया जाता है, तो उसके द्वारा आरोपित बाधाओं को भी ध्यान में रखना चाहिए.
उदाहरण के लिए, एक वर्ग codice_1 पर विचार करें जिसमें व्यक्ति का नाम, पता, फोन नंबर, उम्र, लिंग और जाति शामिल हो. हम codice_1 के codice_3 नामक उपवर्ग को परिभाषित कर सकते हैं जिसमें व्यक्ति के ग्रेड-पाइंट औसत और ली गई कक्षाएं शामिल हैं और codice_4 नामक codice_1 के एक अन्य उपवर्ग में व्यक्ति का कार्य-शीर्षक, नियोजक, तथा वेतन शामिल हैं।
इस वंशानुगत पदानुक्रम को परिभाषित करते समय, हमने पहले से ही कुछ प्रतिबंधों को परिभाषित किया है, जिनमें सभी वांछनीय नहीं हैं:
समग्र पुनः प्रयोग सिद्धांत वंशानुक्रम के लिए एक विकल्प है। यह तकनीक प्राथमिक वर्ग पदानुक्रम से व्यवहारों को अलग करते हुए और किसी व्यावसायिक क्षेत्र के वर्ग द्वारा अपेक्षित विशिष्ट व्यवहार वर्गों को शामिल करते हुए, बहुरूपता और कोड के पुनः प्रयोग का समर्थन करता है। यह दृष्टिकोण कार्यावधि में व्यवहार परिवर्तनों को अनुमत करते हुए, वर्ग पदानुक्रम के स्थैतिक स्वभाव का परिहार करता है और अपने पूर्वज वर्गों के व्यवहारों तक प्रतिबंधित करने के बजाय, एकल वर्ग को व्यवहार की बफ़े शैली लागू करने की अनुमति देता है।
कभी-कभी भूमिकाओं की जगह वंशानुक्रम-आधारित डिज़ाइन का इस्तेमाल किया जाता है। एक भूमिका, मान लें एक व्यक्ति द्वारा छात्र की भूमिका, मौजूद ऑब्जेक्ट के साथ जुड़े लक्षणों को परिभाषित करता है, क्योंकि ऑब्जेक्ट, किसी अन्य ऑब्जेक्ट के साथ कुछ रिश्ते में  भाग लेता रहा होता है (मान लें छात्र की भूमिका में व्यक्ति - कक्षा में - भर्ती हुआ है). कुछ ऑब्जेक्ट-ओरिएंटेड डिज़ाइन प्रणालियां, वस्तुओं के अधिक स्थिर पहलुओं से भूमिकाओं के इस प्रयोग में अंतर नहीं देखतीं. इस प्रकार मॉडल भूमिकाओं में वंशानुक्रम के उपयोग की प्रवृत्ति मौजूद है, कह सकते हैं कि एक व्यक्ति के छात्र की भूमिका को व्यक्ति के उप-वर्ग के स्वरूप में गढ़ा जा सकता है। लेकिन, ना तो वंशानुगत पदानुक्रम और ना ही वस्तुओं के प्रकार समय के साथ बदल सकते हैं। इसलिए, भूमिकाओं को उप-वर्गों के रूप में गढ़ने से, सृजन पर भूमिकाओं के नियत होने का कारण बन सकती है, मान लें कि एक व्यक्ति परिस्थितियों के बदलने पर, आसानी से कर्मचारी को छात्र के रूप में अपनी भूमिका नहीं बदल सकता है। मॉडलिंग के दृष्टिकोण से, अक्सर ऐसे प्रतिबंध वांछनीय नहीं हैं, क्योंकि यह वस्तु प्रणाली के भावी विस्तार पर कृत्रिम प्रतिबंध लगाती है, जिससे भविष्य में परिवर्तनों को लागू करना कठिन हो सकता है, क्योंकि वर्तमान डिज़ाइन को अद्यतन करने की ज़रूरत होगी. वंशानुक्रम को अक्सर सामान्यीकरण मानसिकता के साथ इस प्रकार बेहतर तरीक़े से इस्तेमाल में लाया जा सकता है कि सोदाहरण प्रस्तुति वर्ग के सामान्य पहलुओं को सुपर-क्लास के कारक बनाए जाते हैं; मान लें व्यक्ति और कंपनी दोनों वर्गों के लिए, दोनों के ही सभी सामान्य पहलुओं के लिए एक सामान्य सुपर-क्लास 'क़ानूनी-इकाई' मौजूद है। भूमिका-आधारित डिज़ाइन और वंशानुक्रम-आधारित डिज़ाइन के बीच पहलू की स्थिरता के आधार पर अंतर किया जा सकता है। भूमिका-आधारित डिज़ाइन का इस्तेमाल उस समय किया जाए जब यह कल्पना की जा सकती है कि वही वस्तु अलग समय पर अलग-अलग भूमिकाओं में भाग लेती है और वंशानुक्रम आधारित डिज़ाइन का उपयोग उस समय किया जाए जब कई वर्गों के (वस्तुएं नहीं!) सामान्य पहलुओं को सुपर-क्लास के कारक बनाए जाएं और वे समय के साथ बदलते ना हों.
भूमिकाओं और सुपर-क्लास के अलगाव का एक परिणाम यह है कि इससे ऑब्जेक्ट प्रणाली के संकलन समय और कार्यावधि के पहलुओं को स्पष्ट रूप से अलग किया जा सकता है। इस तरह स्पष्ट रूप से वंशानुक्रम संकलन-समय निर्माण है। वंशानुक्रम कार्यावधि में कई वस्तुओं की संरचना को प्रभावित करता है, लेकिन संरचना के विभिन्न प्रकार, जिनका इस्तेमाल किया जा सकता है, संकलन-समय में पहले ही निर्धारित हो चुका होता है।
इस पद्धति से कर्मचारी के रूप में codice_1 के उदाहरण को मॉडल करने के लिए, मॉडलिंग सुनिश्चित करता है कि एक codice_1 वर्ग में केवल ऐसे परिचालन या डाटा मौजूद हैं जो इस बात का लिहाज़ किए बिना कि उनका उपयोग कहां हो रहा है, प्रत्येक व्यक्ति उदाहरण के लिए आम हैं। इससे व्यक्ति वर्ग में नौकरी करने वाले सदस्य का उपयोग रोका जाएगा, क्योंकि हर व्यक्ति के पास नौकरी नहीं हो सकती है, या कम से कम यह ज्ञात नहीं होगा कि व्यक्ति वर्ग का इस्तेमाल केवल मॉडल नौकरी करने वाले व्यक्ति उदाहरणों के लिए ही किया जा रहा है। इसके बजाय, ऑब्जेक्ट-ओरिएंटेड डिज़ाइन, सभी व्यक्ति ऑब्जेक्टों के कुछ सब-सेट पर "कर्मचारी" की भूमिका में विचार करेगा. नौकरी की जानकारी केवल कर्मचारी भूमिका वाले ऑब्जेक्टों के साथ संबद्ध की जाएगी. ऑब्जेक्ट-ओरिएंटेड डिज़ाइन "नौकरी" को भी भूमिका के रूप में मॉडल करेगा, क्योंकि नौकरी को समय में प्रतिबंधित किया जा सकता है और इसलिए एक वर्ग मॉडलिंग के लिए यह स्थाई आधार नहीं है। सुसंगत स्थिर अवधारणा या तो "कार्यस्थल" है या बस "काम", जो कि अवधारणा के आशय पर निर्भर करता है। इस प्रकार, ऑब्जेक्ट-ओरिएंटेड डिज़ाइन की दृष्टि से, एक "व्यक्ति" वर्ग और एक "कार्यस्थल" वर्ग हो सकता है, जो कई "में-काम करता है" से इस तरह जुड़ा होता है कि व्यक्ति का एक उदाहरण, कर्मचारी की भूमिका में है, जब वह एक नौकरी करता है, जहां एक नौकरी उसके कार्य-स्थल की भूमिका उस स्थिति में है, जिसमें वह कर्मचारी काम करता है।
ध्यान दें कि इस दृष्टिकोण से, सभी वर्ग जो इस डिज़ाइन प्रक्रिया से निर्मित हैं, एक ही डोमेन के हिस्से हैं, अर्थात् वे एक ही शब्दावली के प्रयोग द्वारा विषय को स्पष्ट रूप से परिभाषित करते हैं। कई बार यह अन्य तरीकों के लिए सही साबित नहीं होता.
विशेषतः भूमिकाओं और वर्गों के बीच अंतर को समझना मुश्किल हो जाता है यदि कोई संदर्भिक पारदर्शिता ग्रहण कर लें, चूंकि भूमिकाएं संदर्भों के प्रकार हैं और वर्ग संदर्भित वस्तुओं के प्रकार हैं।