रेक 2: वर्चुअल इनहेरिटेंस

एकाधिक वंशानुक्रम चीजों को कैसे जटिल करता है, इस पर एक लेख। पहली नज़र में, आभासी विरासत को अतार्किक रूप से लागू किया जाता है। दूसरी नज़र में, तर्क प्रकट होता है, लेकिन जटिलता और जटिलता का स्तर बढ़ता रहता है। सामान्य तौर पर, कार्य जितना कठिन होता है, आपको साधनों का चयन करने की उतनी ही सरल आवश्यकता होती है।

सब कुछ वास्तविक घटनाओं पर आधारित है, लेकिन उदाहरणों को यथासंभव सरल किया गया था ताकि समस्या का केवल सार उनमें बना रहे।

इसलिए, विकसित अनुप्रयोग में बड़ी संख्या में समान रूप से संसाधित निकाय का उपयोग किया गया था। इसके अलावा, उनमें से कुछ को प्रदर्शित किया गया था, अन्य को लगातार अद्यतन करने की आवश्यकता थी, अन्य ने दोनों को संयुक्त किया। तदनुसार, तीन आधार वर्गों को लागू करने की इच्छा थी

1. रेंडर करने योग्य : एक दृश्यता टैग और एक ड्राइंग विधि शामिल है
2. अद्यतन करने योग्य: गतिविधि का संकेत और एक राज्य अद्यतन विधि शामिल है
3. VisualActivity = रेंडर करने योग्य + अद्यतन करने योग्य

जो मुश्किलें हुई हैं, उन्हें प्रदर्शित करने के लिए मैं दो और कृत्रिम कक्षाएं जोड़ूंगा।

1. जस्टविवेबल : बस एक दृश्यमान वस्तु
2. जस्टविजबलप्लसविजुअल एक्टिविटी : जस्टएविजिबल विथ अपडेटेबल स्टेट

यह निम्नलिखित चित्र को दर्शाता है


समस्या तुरंत दिखाई देती है - अंतिम वर्ग दो बार रेंडर करने योग्य है: जस्टविविज़ुअल एंड विजुअलएक्टिविटी के जनक के रूप में। यह प्रदर्शित वस्तुओं की सूची के साथ ठीक से काम नहीं करता है।

JustVisiblePlusUpdate* object = new JustVisiblePlusUpdate; std::vector<Renderable*> vector_visible; vector_visible.push_back(object); 

यह अस्पष्ट रूपांतरणों का पता लगाता है - संकलक यह पता नहीं लगा सकता है कि यह किसके बारे में अनुवांशिक शाखा को विरासत में मिला है। वह मध्यवर्ती के प्रकार को स्पष्ट रूप से कास्टिंग करके दिशा निर्दिष्ट करके मदद की जा सकती है

  JustVisiblePlusUpdate* object = new JustVisiblePlusUpdate; std::vector<Renderable*> vector_visible; vector_visible.push_back(static_cast<VisualActivity*>(object)); 

संकलन सफल होगा, केवल त्रुटि रहेगी। हमारे मामले में, समान रेंडर करने की आवश्यकता थी, भले ही यह कैसे विरासत में मिला हो। तथ्य यह है कि सामान्य वंशानुक्रम के मामले में, वंशज वर्ग (JustVanishPlusVisualActivity) में प्रत्येक शाखा के लिए मूल वर्ग का एक अलग उदाहरण है।


इसके अलावा, उनमें से प्रत्येक के गुणों को स्वतंत्र रूप से बदला जा सकता है। सी ++ में व्यक्त, सच्ची अभिव्यक्ति

 (&static_cast<VisualActivity*>(object)->mVisible) != (&static_cast<JustVisible*>(object)->mVisible) 

इसलिए सामान्य बहुविध विरासत कार्य के लिए उपयुक्त नहीं थी। लेकिन आभासी एक चांदी की गोली की तरह लग रहा था जो कि आवश्यक था ... जो आवश्यक था वह सभी आधार वर्गों को सौंपने के लिए था, वस्तुतः रेंडरेबल और अपडेटेबल , और बाकी सामान्य तरीके से:

 class VisualActivity : public virtual Updatable, public virtual Renderable ... class JustVisible : public virtual Renderable ... class JustVisiblePlusUpdate : public JustVisible, public VisualActivity 

सभी वस्तुतः विरासत में प्राप्त वर्गों को केवल एक बार वंशज में दर्शाया गया है। और सब कुछ काम करेगा अगर बेस कक्षाओं में पैरामीटर के साथ कंस्ट्रक्टर नहीं थे। लेकिन ऐसे डिजाइनर मौजूद थे, और एक आश्चर्य था। वस्तुतः विरासत में मिली कक्षा में एक डिफ़ॉल्ट कंस्ट्रक्टर और एक पैरामीटर दोनों था

 class Updatable { public: Updatable() : mActive(true) { } Updatable(bool active) : mActive(active) { } //.... }; 

 class Renderable { public: Renderable() : mVisible(true) { } Renderable(bool visible) : mVisible(visible) { } //.... }; 

अवर श्रेणी में केवल पैरामीटर के साथ कंस्ट्रक्टर होते थे

 class VisualActivity : public virtual Updatable, public virtual Renderable { public: VisualActivity(bool visible, bool active) : Renderable(visible) , Updatable(active) { } //.... }; 

 class JustVisible : public virtual Renderable { public: JustVisible(bool visible) : Renderable(visible) { } //.... }; 

 class JustVisiblePlusUpdate : public JustVisible, public VisualActivity { public: JustVisiblePlusUpdate(bool visible, bool active) : JustVisible(visible) , VisualActivity(visible, active) { } //.... }; 

और फिर भी, एक वस्तु बनाते समय

  JustVisiblePlusUpdate* object = new JustVisiblePlusUpdate(false, false); 

डिफ़ॉल्ट रेंडर करने योग्य निर्माता को बुलाया गया था! पहली नज़र में, यह कुछ जंगली जैसा लग रहा था। लेकिन आइए इस बात पर करीब से नज़र डालें कि यह धारणा कहाँ से आई है, कि दिए गए कोड को रेंडर करने योग्य :: Renderable :: Renderable () के बजाय निर्माता Renderable :: Renderable (बूल दिखाई) को कॉल करना चाहिए।


Renderable को चमत्कारिक रूप से JustV अदृश्य , VisualActivity और JustVawarePlusUpdate के बीच विभाजित करने की धारणा ने एक समस्या को जन्म दिया । लेकिन "चमत्कार" होने के लिए किस्मत में नहीं था। आखिरकार, ऐसा कुछ लिखना संभव होगा

 class JustVisiblePlusUpdate : public JustVisible, public VisualActivity { public: JustVisiblePlusUpdate(bool active) : JustVisible(true) , VisualActivity(false, active) { } //.... }; 

कंपाइलर परस्पर विरोधी जानकारी को बताना जब एक ही समय में सही और गलत मापदंडों के साथ रेंडर करने योग्य निर्माण की आवश्यकता होगी। कोई भी क्रमशः ऐसे विरोधाभासों के लिए अवसर नहीं खोलना चाहता था, और तंत्र एक अलग तरीके से काम करता है। हमारे मामले में रेंडर करने योग्य वर्ग अब जस्टवेब्यूअल या विजुअल एक्टिविटी का हिस्सा नहीं है, बल्कि सीधे जस्टविलेप्लस यूडेट के अंतर्गत आता है।


यह बताता है कि डिफॉल्ट कंस्ट्रक्टर को क्यों बुलाया गया - वर्चुअल क्लास कंस्ट्रक्टर्स को अंतिम वारिसों द्वारा बुलाया जाना चाहिए, अर्थात्। काम करने का विकल्प कुछ ऐसा होगा

 class JustVisiblePlusUpdate : public JustVisible, public VisualActivity { public: JustVisiblePlusUpdate(bool visible, bool active) : JustVisible(visible) , VisualActivity(visible, active) , Renderable(visible) , Updatable(active) { } //.... }; 

वर्चुअल इनहेरिटेंस में, प्रत्यक्ष अभिभावक निर्माणकर्ताओं के अलावा, सभी वस्तुतः विरासत वाले वर्गों के कंस्ट्रक्टरों को स्पष्ट रूप से कॉल करना आवश्यक है। यह बहुत स्पष्ट नहीं है और एक गैर-तुच्छ परियोजना में आसानी से याद किया जा सकता है। इसलिए एक बार फिर सच्चाई की पुष्टि हुई: प्रत्येक वर्ग के लिए एक से अधिक खुली विरासत नहीं । यह इसके लायक नहीं है। हमारे मामले में, एक मूल VisualActivity तक सीमित, रेंडरटेबल और अपडेट करने योग्य को अलग करने का निर्णय लिया गया था। इसने कुछ अतिरेक को जोड़ा, लेकिन नाटकीय रूप से समग्र वास्तुकला को सरल बनाया - ट्रैकिंग और सभी आभासी और सामान्य विरासत मामलों को बनाए रखना बहुत महंगा था।