C ++ में प्रोग्रामिंग 35 के मॉड्यूल(module) 35 में आपका स्वागत है।
 हम कई इनहेरिटेंस(inheritance) पर चर्चा कर रहे हैं और हमने निर्माण, विनाश, लेआउट(layout), डेटा(data) सदस्यों, सदस्य कार्यों के बुनियादी तंत्र को देखा है और क्या होता है, अगर कई आधार वर्गों के बीच, यदि डेटा(data) सदस्य या सदस्य फ़ंक्शन(function) समान नामों की नकल करते हैं।
 अब, हम कुछ अधिक एकीकृत उपयोग परिदृश्यों पर गौर करेंगे और बताएंगे कि हमारे पास छात्रों के शिक्षक TA परिदृश्य हैं, जहाँ TA एक छात्र है, TA एक शिक्षक है और दोनों हैं व्यक्ति हैं 
इसलिए, हमारे पास एक हीरे की तरह की स्थिति है और हम इसे हीरे की समस्या कहते हैं, हम देखेंगे कि हम इसे हीरे की समस्या क्यों कहते हैं।
 मैंने पहले ही समझाया है कि यह बहुत सामान्य है कि आपके पास बहु इनहेरिटेंस(inheritance) में मिली क्लास(class) की आधार कक्षाओं के लिए एक सामान्य आधार क्लास(class) होगा।
 तो, आइए हम कोड व्यक्ति को देखने की कोशिश करते हैं, जो एक क्लास(class) है, यहाँ मैंने इसे संकाय कहा है, उदाहरण में मैंने इसे संकाय कहा है, जिसका अर्थ है कि शिक्षक एक कक्षा का छात्र है एक क्लास(class) है इसलिए वे एक व्यक्ति से इनहेरिटेंस(inheritance) में मिलते हैं।
 तो, और फिर टीए दोनों संकाय और छात्र से इनहेरिटेंस(inheritance) में मिला, इसलिए यह परिदृश्य है।
 और बस हर निर्माणकर्ता को देखने के लिए एक संदेश है कि निर्माण पर क्या हो रहा है।
 इसलिए, निर्माण में निश्चित रूप से आधार क्लास(class) का निर्माण करना होगा।
 तो, टीए ऑब्जेक्ट(object) के निर्माण के लिए क्या करना होगा, संकाय का निर्माण करना होगा।
 अब, संकाय में व्यक्ति से विशेषज्ञता है।
 तो, एक संकाय ऑब्जेक्ट(object) के निर्माण के लिए क्या करने की आवश्यकता होगी एक व्यक्ति को निर्माण करना होगा, इसलिए ये दोनों एक संकाय ऑब्जेक्ट(object) का निर्माण करते हैं।
 फिर छात्र को निर्माण करना पड़ता है और छात्र व्यक्ति से विशेषज्ञता प्राप्त करता है।
 इसलिए, अगर मुझे एक छात्र का निर्माण करना है तो मुझे फिर से एक व्यक्ति का निर्माण करना होगा।
 तो, एक और व्यक्ति का निर्माण होगा और फिर छात्र का निर्माण होगा, फिर टीए का निर्माण होगा।
 इसलिए, अगर मैं कुल ऑब्जेक्ट(object) परिदृश्य में देखता हूं, तो मेरे पास दो आधार कक्षाएं हैं यह संकाय है और यह एक छात्र है।
 और यह एक व्यक्ति होगा, इसके पास एक व्यक्ति होगा, जिसके पास आपके पास अलग-अलग संकाय डेटा(data) होगा, आपके पास यहां छात्र डेटा(data) होगा, आपके पास व्युत्पन्न क्लास(class) होगा यह टीए ऑब्जेक्ट(object) है।
 तो, आपके पास टीए डेटा(data) होगा यहां ये टीए डेटा(data) हैं।
 लेकिन यह वास्तव में निर्माण कैसे होगा।
 इसलिए, यह ध्यान रखना दिलचस्प है कि जब आप इस तरह का निर्माण करते हैं, तो हमारी इनहेरिटेंस(inheritance) का मूल सिद्धांत हमें बताता है कि एक ही TA ऑब्जेक्ट(object) में दो व्यक्ति ऑब्जेक्ट(object) होने चाहिए।
 क्योंकि, अन्यथा संकाय का निर्माण नहीं किया जा सकता है क्योंकि इसमें आधार ऑब्जेक्ट(object) को एम्बेडेड होना चाहिए, छात्र का निर्माण नहीं किया जा सकता है क्योंकि इसमें उस व्यक्ति को एम्बेडेड होना चाहिए।
 इसलिए, TA को फैकल्टी और स्टूडेंट दोनों की जरूरत होती है।
 तो, आपके पास बेस क्लास ऑब्जेक्ट(object) के दो उदाहरण होंगे और यह निश्चित रूप से एक बहुत ही वांछनीय स्थिति नहीं है, क्योंकि निश्चित रूप से टीए के रूप में एक व्यक्ति के पास केवल एक ही विशेषता होगी यदि मेरे पास व्यक्ति क्लास(class) के दो उदाहरण हैं और मैं कैसे जाऊंगा उस में हल, आप कैसे डेटा(data) को बनाए रखने जा रहे हैं।
 तो, यह उस ओर जाता है जिसे विर्तुयल(virtual) इनहेरिटेंस(inheritance) और कई इनहेरिटेंस(inheritance) के रूप में जाना जाता है।
 यह क्या कहता है कि हम कीवर्ड विर्तुयल(virtual) का उपयोग करते हैं, मुझे फिर से एक लाल रंग का उपयोग करने दें, इससे पहले कि इसके बाद कोई फर्क नहीं पड़ता है, चाहे आप इसे सार्वजनिक रूप से लिखें, आप इसे सार्वजनिक रूप से भी लिख सकते हैं, लेकिन आप इसका उपयोग करते हैं कीवर्ड विर्तुयल(virtual), जहां आप इनहेरिटेंस(inheritance) में मिल रहे हैं।
 जब आप ऐसा करते हैं, तो इनहेरिटेंस(inheritance) विर्तुयल(virtual) हो जाता है जिसका अर्थ है कि टीए का निर्माण किया जाना है आपकी पहली बात यह है कि संकाय का निर्माण करना होगा।
 अब, यदि आप कहते हैं कि संकाय व्यक्ति को विर्तुयल(virtual) तरीके से इनहेरिटेंस(inheritance) में मिला है, तो यह जानता है कि कुछ अन्य विशिष्ट क्लास(class) का निर्माण किया जा रहा है, जिसके लिए अन्य आधार क्लास(class) हो सकते हैं।
 इसलिए, संकाय अपने व्यक्ति क्लास(class) का निर्माण नहीं करता है, यह नहीं है कि जहां निर्माण व्यक्ति ऑब्जेक्ट(object) है, उस उदाहरण का निर्माण नहीं करता है।
 इसी तरह, जब हम छात्र करते हैं तो यह छात्र क्लास(class) के व्यक्ति उदाहरण का निर्माण नहीं करता है, अन्यथा मुझे इसकी आवश्यकता होगी।
 लेकिन प्रक्रिया दोनों संकाय के साथ-साथ छात्र के लिए एक सामान्य व्यक्ति उदाहरण का निर्माण करती है।
 अब, इसका निर्माण कैसे होगा, अब निश्चित रूप से संकाय निर्माण नहीं कर रहा है एक छात्र निर्माण नहीं कर रहा है क्योंकि वे वास्तव में व्यक्ति से इनहेरिटेंस(inheritance) में प्राप्त कर रहे हैं।
 तो, यह एक डिफॉल्ट कंस्ट्रक्टर(constructor) होना चाहिए, इसके लिए विर्तुयल(virtual) इनहेरिटेंस(inheritance) की एक प्रक्रिया होनी चाहिए कि एक सिंगल बेस क्लास, यूनीक बेस क्लास इंट्रस्ट बनेगा।
 इसलिए, मैंने यहां व्यक्ति क्लास(class) के लिए एक डिफ़ॉल्ट कंस्ट्रक्टर(constructor) पेश किया है।
 अब, हम देख सकते हैं कि व्यक्ति क्लास(class) का निर्माण उदाहरणों का निर्माण केवल एक बार किया जाता है और उस पर आधारित संकाय और छात्र उदाहरण हैं।
 इसलिए, यदि हम संकाय के आधार क्लास(class) के हिस्से को देखते हैं, तो आप इस व्यक्ति को प्राप्त करते हैं, यदि आप छात्र के आधार क्लास(class) भाग को देखते हैं, तो आपको फिर से उसी व्यक्ति का उदाहरण मिलता है, यदि आप निश्चित रूप से टीए के आधार क्लास(class) के हिस्से को देखते हैं।
 बेशक, आपको एक ही व्यक्ति मिलता है।
 तो, आप आधार क्लास(class) के उदाहरण को विशिष्ट बनाते हैं।
 इसलिए, यह तब होता है जब हम विर्तुयल(virtual) इनहेरिटेंस(inheritance) का उपयोग करते हैं और रूट क्लास के कई उदाहरणों से बचने के लिए पदानुक्रम(hierarchy) का निर्माण इस प्रकार करते हैं, डायमंड क्लास के कई उदाहरणों को व्युत्पन्न क्लास(class) के उदाहरण में, हम विर्तुयल(virtual) इनहेरिटेंस(inheritance) और ऐसी कक्षाओं का उपयोग करते हैं जिन्हें विर्तुयल(virtual) बेस क्लास के रूप में जाना जाता है।
 तो, यह एक विर्तुयल(virtual) बेस क्लास है, यह एक विर्तुयल(virtual) बेस क्लास है, ये विर्तुयल(virtual) बेस क्लास VBCs हैं।
 क्योंकि वे सीधे अपने आधार क्लास(class) भाग का निर्माण नहीं करेंगे; बेस क्लास भाग का उदाहरण जो कुल, व्युत्पन्न क्लास(class) ऑब्जेक्ट(object) के साथ सामान्य होगा।
 अब, इस प्रक्रिया में यह हीरे के मामले में ऑब्जेक्ट(object) लेआउट की एक मूल समस्या को हल करता है, यही कारण है कि यदि आपके पास हीरा है।
 ताकि, इस क्लास(class) का निर्माण यहाँ होने के साथ-साथ हो रहा है।
 तो, विर्तुयल(virtual) इनहेरिटेंस(inheritance) मूल रूप से उस समस्या को समाप्त कर देती है, लेकिन एक छोटे प्रतिबंध के साथ जो ऐसा करने के लिए।
 चूंकि हमने यह स्वचालित रूप से किया है इसलिए हम केवल डिफ़ॉल्ट कंस्ट्रक्टर(constructor) व्यक्ति क्लास(class) का उपयोग कर सकते हैं।
 तो, क्या होगा अगर मैं उस व्यक्ति क्लास(class) के मापदंडों को पास करना चाहता हूं जो कि अगर मैं इस निर्माता को कॉल करना चाहता हूं।
 यह है कि यह बहु इनहेरिटेंस(inheritance) में ऐसा करने का बहुत ही सरल तरीका है, आपको बस इतना करना है कि ये वही हैं जो आपको इनहेरिटेंस(inheritance) में मिले हैं, वस्तुतः यह इनहेरिटेंस(inheritance) में मिला है, ये VBCs विर्तुयल(virtual) बने रहेंगे आधार क्लास(class) जो सभी समान रहते हैं।
 एकमात्र अंतर टीए क्लास(class) के कंस्ट्रक्टर(constructor) में है, उस के कंस्ट्रक्टर(constructor) में, व्युत्पन्न क्लास(class) के कंस्ट्रक्टर(constructor) में आप स्पष्ट रूप से रूट क्लास के कंस्ट्रक्टर(constructor) को कॉल करते हैं और वहां आप मापदंडों को पास करते हैं।
 तो, यदि आप ऐसा करते हैं तो क्या होगा, यह पहला निर्माण होगा जो इस निर्माता को कॉल करेगा जिसके पास पैरामीटर है।
 फिर इस ऑर्डर के अनुसार यह कॉल करने के लिए अगला होगा और यह अंतिम होगा जिसे कॉल किया जाएगा इसलिए आप देखेंगे कि यह व्यक्ति संकाय छात्र है और टीए कंस्ट्रक्टर(constructor) उस क्रम में है कि इसका निर्माण होगा।
 और आपके पास अभी भी है कि मूल समस्या हल हो गई है आपके पास आधार क्लास(class) का एक अनूठा उदाहरण है, लेकिन आप निर्माणकर्ता को पैरामीटर पास करने में सक्षम हैं।
 तो, यह एक बहु इनहेरिटेंस(inheritance) पदानुक्रम(hierarchy) के निर्माण का मूल तरीका है।
 और अब आप आगे बढ़ सकते हैं और उस पॉलीमोर्फिक(polymorphic) को और एक सदस्य को पढ़ाने का तरीका बता सकते हैं कि व्यक्ति का आधार क्लास(class) इसे विशुद्ध रूप से विर्तुयल(virtual) बनाता है, क्योंकि एक व्यक्ति जिसे आप नहीं जानते कि कोई व्यक्ति कैसे सिखा सकता है, इसलिए तात्कालिकता कि, एक गैर-शुद्ध विर्तुयल(virtual) फ़ंक्शन(function) के रूप में संकाय में लागू करें, फिर से छात्र और इतने पर।
 लेकिन जैसा कि आप करते हैं कि निश्चित रूप से आपके पास इस संदर्भ में एक संघर्ष होगा कि क्या आप इसका उपयोग करेंगे या आप इसका उपयोग करेंगे और एक बहुरूपीय पदानुक्रम(hierarchy) पर निश्चित रूप से आप हमें यह निर्दिष्ट नहीं कर सकते हैं कि आप किस सदस्यीय फ़ंक्शन(function) का उपयोग करेंगे जैसे आपने गैर के मामले में किया नॉन-पॉलिमॉर्फिक विधि का उपयोग करे।
 तो, जिस तरह से आप इसका लाभ उठा सकते हैं, वह वास्तव में टीए क्लास(class) में एक नए सदस्य फ़ंक्शन(function) के उपयोग से दोनों को ओवरराइड करता है।
 यदि आप ऐसा नहीं करते हैं, तो निश्चित रूप से, जब आप टीए का एक उदाहरण करने की कोशिश करते हैं, तो यह कहेगा कि हम ऐसा नहीं कर सकते क्योंकि आपको नहीं पता कि इन दोनों में से कौन सा शिक्षण कार्य इस ऑब्जेक्ट(object) का उपयोग करना चाहिए।
 इसलिए, एक बार जब आप यह लिख चुके होते हैं, तो इसका मतलब है कि आप इसे सीधे विर्तुयल(virtual) फंक्शन(function) टेबल(table) में छिपा देते हैं, फिर आप यह कर सकते हैं कि कोड काम करेगा और फिर अगलाआप क्या करना चाहते हैं इस पर निर्भर करेगा।
 यदि आप इस फ़ंक्शन(function) का पुनः उपयोग करना चाहते हैं, तो TA क्लास(class) में पढ़ाने के कार्यान्वयन के भीतर आप निश्चित रूप से इसका उल्लेख संकाय बृहदान्त्र(colon) बृहदान्त्र(colon) द्वारा सिखा सकते हैं या यदि आप छात्र क्लास(class) के शिक्षण का पुन: उपयोग करना चाहते हैं, तो आप छात्र बृहदान्त्र(colon) उपनिवेश का उपयोग कर सकते हैं या आप लागू कर सकते हैं अपने दम पर।
 तो, यह हीरे की संरचना के साथ कई इनहेरिटेंस(inheritance) के मामले में अस्पष्टता का मूल मुद्दा है, जब तक आपके पास हीरे की संरचना नहीं होगी, हमारे पास यह नहीं होगा।
 इसका कारण आपको मिल रहा है, क्योंकि आपके पास हीरा है।
 इसलिए, चूंकि आपके पास हीरा है, इसलिए दो तरीके हैं कि सिखाने का कार्य यहां तक पहुंच सकता है, दो तरीके जो सिखा सकते हैं यहां तक पहुंच सकते हैं, यदि आपके पास अधिक आधार कक्षाएं और एक सामान्य हीरा है तो आपके पास ऐसा करने के अधिक तरीके होंगे, लेकिन भ्रम के लिए दो पर्याप्त है।
 तो, यहाँ आपको यह नहीं पता है कि आपको इस के पढ़ाने का उपयोग करना चाहिए या आप को इस का उपयोग करना चाहिए।
 तो, यह एक बुनियादी समस्या है और यह कि अगर आप वास्तव में एक सामान्य कई इनहेरिटेंस(inheritance) पदानुक्रम(hierarchy) चाहते हैं जो कई मुद्दों की ओर जाता है।
 और अधिक बार कई संगठन बताते हैं कि आपको वास्तव में इसका उपयोग नहीं करना चाहिए, बेशक, कई इनहेरिटेंस(inheritance) परिदृश्यों में हीरे का उपयोग नहीं करना चाहिए, जो कि कई इनहेरिटेंस(inheritance) के कुल उपयोग को गंभीर तरीके से प्रतिबंधित करता है।
 लेकिन यह एक गंभीर व्याख्या समस्या है जिसके साथ रहना होगा।
 तो, इस संदर्भ में, वहाँ एक है; यह एक अभ्यास है, जहां एक क्लास(class) ए है, एक क्लास(class) बी है।
 इसलिए एक क्लास(class) ए, क्लास(class) बी है और फिर एक क्लास(class) सी है और फिर एक कक्षा डी है।
 इसलिए, यह एक परिदृश्य है जैसे इस।
 तो, यह फिर से कई इनहेरिटेंस(inheritance) का एक परिदृश्य है, लेकिन यह बिल्कुल हीरा नहीं है।
 तो, इस पर अलग-अलग सदस्य कार्य foo और foobar परिभाषित हैं।
 इसलिए, मैं आपको केवल सुझाव दूंगा कि आप उन सभी को जानते हैं जो आपने एक इनहेरिटेंस(inheritance) में और साथ ही कई इनहेरिटेंस(inheritance) में अध्ययन किए हैं।
 आप विभिन्न श्रेणी की वस्तुओं के उदाहरण बनाने की कोशिश करते हैं, विभिन्न प्रकार के बिंदुओं को लेने की कोशिश करते हैं और यह बताने की कोशिश करते हैं कि आप इस पदानुक्रम(hierarchy) पर विभिन्न सदस्य कार्यों को कैसे लागू कर सकते हैं।
 बेशक, आप अंत में, सी से ए को व्युत्पन्न करके पूरी चीज़ को जटिल बना सकते हैं, जिस क्षण आप ए को हीरे से प्राप्त करने की अनुमति देते हैं और आप में आने वाली अस्पष्टता की दिलचस्प समस्या होगी।
 इसलिए, आखिरकार, मैं बंद होने से पहले, मैं आपको केवल डिज़ाइन की पसंद के एक मुद्दे की झलक देना चाहूंगा, जैसे कि हम हमेशा इनहेरिटेंस(inheritance) के संदर्भ में मॉडल कर सकते हैं और इसके स्थान पर हम रचना भी कर सकते हैं दूसरी तरह से पदानुक्रम।
 और डिजाइनरों में हमेशा एक व्यापार होता है कि क्या आपको इनहेरिटेंस(inheritance) करना चाहिए या आपको रचना करनी चाहिए।
 तो, हो सकता है कि आपको यह दिखाने के लिए यहां एक उदाहरण बनाया गया हो कि आप किस तरह की कठिनाइयों को स्वीकार करते हैं।
 उदाहरण के लिए, मैं वाहन पदानुक्रम(hierarchy) को देख रहा हूं और ये प्राथमिक हैं जो आप वाहन के उप-वर्गों को जानते हैं जो आप देख रहे हैं कि पहिया वाहनों का क्लास(class) दुनिया में मौजूद है।
 और जहां विभिन्न प्रकार के ड्राइविंग तंत्र, इंजन(engine) क्लास(class) मूल रूप से अलग-अलग ड्राइव तंत्र हैं, जो उसके लिए हो सकते हैं और यदि आप उस पर ध्यान देते हैं तो पहिएदार के संदर्भ में, आपके पास एक दो पहिया वाहन हो सकता है, आपके पास एक तीन पहिया वाहन हो सकता है और आपके पास एक चार पहिया वाहन हो सकता है ये विभिन्न विकल्प हैं।
 और इंजन(engine) क्लास(class) के संदर्भ में आपके पास एक मैनुअल(manual) ड्राइव हो सकती है जिसमें आप एक पेट्रोल(petrol) द्रव ड्राइव कर सकते हैं जो आपके पास एक इलेक्ट्रिक(electric) ड्राइव हो सकती है ये सभी अलग-अलग प्रकार हैं।
 इसलिए, यदि आपके पास ये सब है, तो मूल रूप से आपके पास दो प्रमुख पदानुक्रम(hierarchy) हैं, जो व्हील ड्राइव के आधार पर, एक इंजन(engine) क्लास(class) पर आधारित है।
 तो, अगर आप उस पर नजर डालते हैं, तो उनके आधार पर आपके पास बहुत सारी IF कक्षाएं होती हैं जो विभिन्न संयोजनों पर आधारित होती हैं, जैसे कि मैं एक साइकिल के बारे में बात कर सकता हूं, जो मैनुअल(manual) और थ्री व्हीलर है।
 इसलिए, यह बहु इनहेरिटेंस(inheritance) में हो रहा है, मेरे पास एक कार है जो एक चार पहिया वाहन है और पेट्रोल(petrol) तरल पदार्थ है जो मेरे पास एक इलेक्ट्रिक(electric) कार है, जो चार पहिया वाहन है, लेकिन इलेक्ट्रिक(electric) तरल पदार्थ और इतने पर।
 इसलिए, मेरे पास तीन प्रकार के पहिए वाले वाहन हैं, मेरे पास तीन प्रकार के इंजन(engine) ड्राइव हैं।
 इसलिए, वास्तव में मेरे पास तीन में तीन नौ संयोजन हैं और कई जीवित क्लास(class) हो सकते हैं जिनके पास एक ही आधार क्लास(class) माता-पिता हैं।
 तो, आपके पास वास्तव में नौ से अधिक विस्फोटक प्रकार के संयोजन होंगे जो लाइव स्तर पर समान रूप से विस्फोटक प्रकार के संयोजन प्राप्त करते हैं।
 तो, यह मॉडलिंग के संदर्भ में काफी है, लेकिन जब आपको वास्तव में कोड को प्रबंधित करना होगा, और इन पूरे पदानुक्रमों को याद रखना चाहिए और इस शीर्ष पर तर्क को पसंद करते हैं, तो हर चरण में यह तय करना कि क्या इनहेरिटेंस(inheritance) में मिला है।
 और आप जानते हैं कि आपको क्या उपयोग करना चाहिए और आपको क्या ओवरराइड करना चाहिए, यह डिज़ाइन में बहुत अच्छी सहायता नहीं बनती है बल्कि यह एक बाधा बन जाती है।
 तो, एक सामान्य नुस्खा क्या है, यदि आपके पास एक डोमेन में कई संभावित पदानुक्रम(hierarchy) हैं, तो आपको एक का चयन करना चाहिए, जो कि प्रमुख है, यह देखने का एक तरीका है जो आपकी मदद कर सकता है कई स्थानों पर कई इनहेरिटेंस(inheritance) के बारे में पढ़ें वाहन पदानुक्रम(hierarchy) के रूप में है।
 इसलिए, मैं सिर्फ पहिएदार वाहनों के पदानुक्रम(hierarchy) को देख रहा हूं।
 इसलिए, मैं इंजन(engine) प्रकारों को नहीं देख रहा हूं।
 इसलिए, जब भी मैं किसी भी प्रकार के व्युत्पन्न वाहन को ऑब्जेक्ट(object) बनाऊंगा, तब मैं क्या करूंगा।
 तो, ये अलग-अलग पहिए वाले वाहन हैं जो चार, तीन, दो हैं और फिर आपके पास सभी बेस क्लास हैं।
 इसके लिए मेरे पास इस ऑब्जेक्ट(object) में एक इंजन(engine) स्टार होगा जो इंजन(engine) को इंगित करेगा और यह मूल रूप से इंजन(engine) क्लास को इंगित करेगा।
 अलग विशेषज्ञता।
 इसलिए, चाहे मेरे पास मैनुअल(manual) हो, चाहे मेरे पास बिजली हो, चाहे मेरे पास पेट्रोल(petrol) द्रव हो, इत्यादि, इस ऑब्जेक्ट(object) को दो पदानुक्रमों से संयुक्त रूप से प्राप्त करने के बजाय, मैं इसे विशेष रूप से व्हील साइड पर एक के बाद एक यहां प्राप्त करूंगा और फिर इंजन(engine) पदानुक्रम(hierarchy) का उल्लेख करूंगा।
 एक सदस्य, एक रचना के रूप में।
 तो, यह पॉइंटर(pointer) तब विशेष प्रकार के इंजन(engine) को ले जाएगा जैसा मैं चाहता हूं।
 बेशक, अगर मैं ऐसा कर रहा हूं, तो निश्चित रूप से मैं दूसरे तरीके से कर सकता हूं, मैं फिर से एक वाहन पदानुक्रम(hierarchy) कर सकता हूं, जो मूल रूप से इंजन(engine) क्लास(class) पर आधारित है।
 इसलिए, मेरे पास इलेक्ट्रिक(electric) इंजन(engine), पेट्रोल(petrol) ईंधन इंजन(engine), मैनुअल(manual) इंजन(engine) है, मेरे पास उस पर मेरी लीफ लेबल कक्षाएं हैं, लेकिन अब एक पहिया में मेरे पास व्हील पॉइंटर(pointer) है, जो मूल रूप से मुझे टू व्हीलर, थ्री व्हीलर, फोर व्हीलर का पदानुक्रम(hierarchy) बताता है और इसी तरह।
 और मैं मुख्य रूप से एक प्रमुख पदानुक्रम(hierarchy) के रूप में इंजन(engine) प्रकार पर काम करता हूं और इस वाहन प्रकार के अन्य एक एचएएसए(HASA) या घटक का उपयोग करता हूं।
 तो, या तो किया जा सकता है, अगर कई इनहेरिटेंस(inheritance) संरचना में कई सूचनाएं हैं जो मौजूद हैं तो आपके पास ऐसे कई विकल्प होंगे।
 और सबसे अधिक निर्धारित और अधिक इस्तेमाल की जाने वाली शैली क्या आप उनमें से किसी एक की पहचान करते हैं, इनहेरिटेंस(inheritance) के विभिन्न विकल्पों में से एक एक पदानुक्रम(hierarchy) है जो आपको मिल रहा है, उनमें से एक की पहचान करें जो प्रमुख है और एक एकल बहु-स्तरीय है और आप जानते हैं उस पर एक पदानुक्रम(hierarchy) का।
 और सभी अन्य पदानुक्रम(hierarchy) जो आपको मिल रहे हैं वे सभी एक इंजन(engine) की तरह एक रिश्ता है जिसे हमने यहां देखा था उन्हें अपने घटकों में बनाते हैं।
 और फिर आप उस घटक की यात्रा करते हैं और इस तरह विशेष पदानुक्रम(hierarchy) में जाते हैं।
 और इस पदानुक्रम(hierarchy) पर इंजन(engine) प्रकार के बारे में तर्क दें यदि आप चाहते हैं कि आप गाड़ी के प्रकार के संदर्भ में एक और पदानुक्रम(hierarchy) चाहते हैं जैसे कि यह यात्रियों के लिए है, चाहे वह सामान के लिए हो, चाहे वह हिरासत के लिए हो और इसी तरह।
 तो, तदनुसार आपको इसे करना होगा; अब यह एक ऐसा विकल्प है जो एक प्रमुख है जो एक पदानुक्रम(hierarchy) पर होना चाहिए।
 इसलिए, कि आप वास्तव में उस पर पॉलीमोर्फिक(polymorphic) कोड लिख सकते हैं और फिर वैकल्पिक पदानुक्रम(hierarchy) में विभिन्न घटकों को संदर्भित कर सकते हैं।
 और कई डिजाइन तकनीकें हैं जिनके द्वारा आप एक डबल प्रेषण के रूप में जाना जा सकता है जैसे कि आप संयुक्त रूप से दो स्वतंत्र पदानुक्रमों पर निर्णय ले सकते हैं और वास्तव में एक बहुरूपीय फ़ंक्शन(function) को भेजते हैं जो इस कोर्स के दायरे से परे होगा क्योंकि आप अधिक से अधिक विशेषज्ञ बन जाते हैं।
 , आप वह सब सीख और देख पाएंगे।
 इसलिए, इस मॉड्यूल(module) में दो व्याख्यानों को संक्षेप में प्रस्तुत करने के लिए, हमने कई उत्तराधिकार की अवधारणाओं को पेश किया है, हमने मूल शब्दार्थ को समझाया है।
 और मैंने आपको केवल यह दिखाने की कोशिश की है कि विभिन्न विरासतें क्या हो सकती हैं, जब आप कई इनहेरिटेंस(inheritance) का उपयोग करते हैं।
 और अंत में, आपको इनहेरिटेंस(inheritance) के उपयोग के बीच एक डिज़ाइन विकल्प के बारे में कुछ विचार देने की कोशिश करें, क्योंकि दृश्य संरचना और संरचना का केवल एक ही तंत्र इनहेरिटेंस(inheritance) और संरचना का मिश्रण बनाता है और एक प्रमुख बहुरूपिक प्रतिनिधित्व के रूप में ऑब्जेक्ट(object) के प्रमुख पदानुक्रम(hierarchy) पर निर्णय लेता है।
 वस्तुओं का।
 और संदर्भ के संदर्भ में अन्य लोगों की रचना का उपयोग करना और फिर उसी के अनुसार अपने पॉलीमोर्फिक(polymorphic) प्रेषण करना।