अधिभार और विरासत

किसी भी प्रोग्रामिंग भाषा में सुविधाओं का एक निश्चित सेट है, जिसे समझने के लिए आपको बस यह जानना होगा कि उन्हें कैसे लागू किया गया है। यहां, उदाहरण के लिए, क्लोजर ; यह एक अत्यधिक जटिल अवधारणा नहीं है, लेकिन यह जानना कि इस जानवर को कैसे डिज़ाइन किया गया है, हमें लूप चर के साथ बंद होने के व्यवहार के बारे में कुछ निष्कर्ष निकालने की अनुमति देता है। बेस क्लास के कंस्ट्रक्टर में वर्चुअल तरीकों को लागू करने के लिए भी यही लागू होता है: कोई एक सही समाधान नहीं है और आपको बस यह जानने की जरूरत है कि भाषा डेवलपर्स ने क्या फैसला किया और क्या उत्तराधिकारी (जैसा कि जावा या सी # में कहा जाएगा), या कंस्ट्रक्टर में "बहुरूपिया" व्यवहार काम नहीं करता है और बेस क्लास विधि को (C ++ की तरह) कहा जाएगा।

एक अन्य प्रकार की समस्या जिसमें एक आदर्श समाधान नहीं है, ओवरलोडिंग विधियों और विधि ओवरराइडिंग का संयोजन है। आइए निम्नलिखित सी # उदाहरण देखें। मान लें कि हमारे पास वर्चुअल विधि फू ( int) और गैर-आभासी विधि फू ( ऑब्जेक्ट) के साथ व्युत्पन्न वर्ग में बेस और व्युत्पन्न की एक जोड़ी है:

class Base { public virtual void Foo(int i) { Console.WriteLine("Base.Foo(int)"); } } class Derived : Base { public override void Foo(int i) { Console.WriteLine("Derived.Foo(int)"); } public void Foo(object o) { Console.WriteLine("Derived.Foo(object)"); } } 

सवाल यह है कि निम्नलिखित मामले में किस विधि को बुलाया जाएगा:

 int i = 42; Derived d = new Derived(); d.Foo(i); 

पहली और सबसे उचित धारणा यह है कि व्युत्पन्न विधि कहा जाता है। फू ( इंट) , क्योंकि 42 एक इंट है , और व्युत्पन्न वर्ग में फू ( इंट) विधि शामिल है। हालांकि, यह वास्तव में मामला नहीं है और व्युत्पन्न विधि कहा जाएगा । फू ( वस्तु) ।

बेशक, स्मार्ट लोग तुरंत विनिर्देश में जाएंगे और निम्नलिखित निष्कर्ष देंगे: संकलक, वे कहते हैं, विधि की घोषणा और पुनर्वित्त को अलग-अलग तरीके से व्यवहार करता है और वह, शुरुआत में, वर्तमान चर (यानी व्युत्पन्न वर्ग में) की कक्षा में उचित विधि की खोज करता है और यदि उचित अधिभार है। यदि यह पाया जाता है (भले ही एक अंतर्निहित प्रकार के रूपांतरण की आवश्यकता होती है), तो यह इस पर शांत हो जाएगा और बेस कक्षाओं (यानी, बेस क्लास) पर विचार करेगा, भले ही वारिस द्वारा पुनर्निर्धारित विधि का अधिक उपयुक्त संस्करण हो।

हालांकि, इस मामले में, यह दिलचस्प नहीं है कि केवल इस तथ्य की घोषणा की जाती है कि विधियों की घोषणा और पुनर्वितरण की अलग-अलग व्याख्या की जाती है और यह कि बेस क्लास के तरीके दूसरी तरह के "तरीके" हैं, और कंपाइलर उनका दूसरा विश्लेषण करते हैं, कि कंपाइलर (या इसके डेवलपर्स) ने कितने कारणों से निर्णय लिया है। इस तरह के व्यवहार को लागू करें।
वर्तमान व्यवहार कितना तार्किक है, इस सवाल का जवाब देने के लिए, आइए एक कदम पीछे लें और इस मामले पर विचार करें। मान लीजिए कि हमारी श्रेणी पदानुक्रम में केवल एक फू ( वस्तु) विधि है, और यह व्युत्पन्न वर्ग में स्थित है:

 class Base {} class Derived : Base { public void Foo(object o) { Console.WriteLine("Derived.Foo(object)"); } } 

हां, बहुत उपयोगी वर्ग पदानुक्रम नहीं है, लेकिन फिर भी। इसमें सबसे महत्वपूर्ण बात यह है कि कोई भी इस बारे में सवाल नहीं उठाएगा कि निम्नलिखित मामले में फू कॉल किसे कहा जाएगा (केवल एक विकल्प है): नया व्युत्पन्न ()। फू (42)।
लेकिन चलो मान लेते हैं कि विभिन्न संगठन, या कम से कम अलग-अलग डेवलपर्स, आधार और व्युत्पन्न वर्गों के विकास में शामिल हैं। चूंकि बेस क्लास का डेवलपर वास्तव में नहीं जानता है कि व्युत्पन्न वर्ग का डेवलपर क्या करता है, वह वारिस वर्ग के डेवलपर्स के ज्ञान के बिना एक बिंदु पर Foo विधि को आधार वर्ग में जोड़ सकता है:

 class Base { public virtual void Foo(int i) { Console.WriteLine("Base.Foo(int)"); } } 

यदि हम मूल प्रश्न का उत्तर देते समय हमारे द्वारा कहे गए सामान्य ज्ञान का अनुसरण करते हैं, तो हमें फू विधि और निम्न कोड का अधिक उपयुक्त अधिभार मिलता है: नया व्युत्पन्न ()। फू (42) को अब आधार विधि और आउटपुट बेस पर कॉल करना चाहिए । फू ( इंट) । हालांकि, यह कितना तर्कसंगत है कि बेस क्लास में बदलाव के बाद, व्युत्पन्न वर्ग के डेवलपर के ज्ञान के बिना, एक अच्छी तरह से परीक्षण किया गया कोड अचानक काम करना बंद कर देता है? बेशक, हम यह कह सकते हैं कि इस मामले में, बेस क्लास की विधि को कॉल न करें और इसे केवल तभी कॉल करेंगे जब व्युत्पन्न वर्ग में कोई अधिभार होगा। लेकिन यह व्यवहार और भी अजनबी होगा।
इस समस्या को सी # भाषा विनिर्देश और एरिक लिपर्ट के ब्लॉग के पाठकों की एक विस्तृत श्रुंखला के लिए जाना जाता है, क्योंकि "भंगुर आधार वर्ग सिंड्रोम" की समस्या है, जिसे प्रोग्रामिंग भाषाओं के अधिकांश डेवलपर्स किसी तरह हल करने की कोशिश करते हैं। इस विशेष मामले में, यह इस तथ्य से हल किया जाता है कि संकलक पहले इस्तेमाल किए गए चर की कक्षा में सीधे घोषित तरीकों का विश्लेषण करता है और केवल एक उपयुक्त विधि की अनुपस्थिति में आधार वर्गों में घोषित तरीकों पर विचार करता है।

अन्य प्रोग्रामिंग भाषाओं के बारे में क्या?

हां, यह सीखना बहुत दिलचस्प होगा कि इस समस्या को अन्य प्रोग्रामिंग भाषाओं में कैसे हल किया जाता है, उदाहरण के लिए, C ++, Java, या शायद एफिल (सबसे परिष्कृत ओओ प्रोग्रामिंग भाषाओं में से कई की राय में)।

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

नोट
वास्तव में, इस तरह की चाल का उपयोग न केवल एफिल भाषा में किया जाता है; इसलिए, उदाहरण के लिए, C # में वर्चुअल ईवेंट्स के साथ कुछ समस्या है, जिसे VB.NET में बहुत ही शान्त तरीके से हल किया गया है - वर्चुअल इवेंट्स को इसमें बस मना किया गया है।

जावा और सी ++ में, चीजें कुछ अलग हैं और यह कारण है, सबसे पहले, जिस तरह से ये भाषाएं व्युत्पन्न वर्ग में विधि को ओवरराइड घोषित करती हैं। इन भाषाओं में, डिफ़ॉल्ट आभासीता के लिए एक अलग दृष्टिकोण का उपयोग किया जाता है (जावा में, सभी विधियां डिफ़ॉल्ट रूप से आभासी हैं, और सी ++ में विधि आभासीता को स्पष्ट रूप से स्पष्ट रूप से घोषित किया जाना चाहिए), लेकिन शुरुआत में उन्होंने उत्तराधिकारी वर्ग में आभासी तरीकों को ओवरराइड करने के लिए एक ही दृष्टिकोण का उपयोग किया:

 class Base { public: virtual void Foo(Integer& i) {} }; class Derived : public Base { public: // : // virtual void Foo(Integer& i) //  // void Foo(Integer& i) override // C++11 //    ! void Foo(Integer& i) {} void Foo(Object& o) {} }; 

जावा और सी ++ में एक विधि को ओवरराइड करने के लिए, आपको किसी भी अतिरिक्त कीवर्ड का उपयोग करने की आवश्यकता नहीं है: यह उत्तराधिकारी वर्ग में समान हस्ताक्षर के साथ एक विधि को लागू करने के लिए पर्याप्त है। और चूंकि, वाक्यविन्यास के दृष्टिकोण से, एक नई विधि की घोषणा से किसी भी तरह से एक पुनर्परिभाषित विधि भिन्न नहीं होती है ( व्युत्पन्न वर्ग के दो तरीकों की तुलना करें), तो यहां व्यवहार C # के समान नहीं होगा।

 Integer i; Derived *pd = new Derived; pd->Foo(i); 

इस मामले में, जैसा कि हमने शुरू में उम्मीद की थी, फू ( इंटेगर एंड) विधि को बुलाया जाएगा।
जावा और सी ++ में, प्रोग्रामर बाद में वारिस में तरीकों को ओवरराइड करने के संदर्भ में अपने इरादों को अधिक सटीक रूप से व्यक्त करने में सक्षम हो गया। जावा में, संस्करण 5 से शुरू होकर, एक विशेष एनोटेशन दिखाई दिया - ओवरराइड , और सी ++ 11 में एक नया कीवर्ड "ओवरराइड" दिखाई दिया। हालांकि, स्पष्ट कारणों के लिए, इन भाषाओं में व्यवहार अपरिवर्तित रहा है।

नोट
वैसे, पिछले मानक की तुलना में C ++ 11 में नया क्या है, इसके विवरण के लिए, Bjarne Straustrup का FAQ अनुवाद देखें: C ++ 11 FAQ ।
सच है, जावा और सी ++ भाषाओं की समानता यहां समाप्त होती है। यदि आप व्युत्पन्न वर्ग में Foo ( Integer &) विधि की टिप्पणी करते हैं, तो Derived :: Foo ( Object &) को C ++ में बुलाया जाएगा (अर्थात अधिक उपयुक्त आधार वर्ग विधि को उम्मीदवार नहीं माना जाएगा), और Java - Base में। फू ( पूर्णांक) ।

निष्कर्ष

ओवरलोड रिज़ॉल्यूशन अपने आप में एक दिलचस्प चीज़ है ( यहाँ पुष्टि के रूप में निकोव के अध्ययनों में से एक है), लेकिन यदि आप इसमें विरासत जोड़ते हैं तो यह और भी जटिल है। एक ओर, C # में वर्तमान व्यवहार गलत लग सकता है, लेकिन यदि आप पेशेवरों और विपक्षों का वजन करते हैं, तो यह काफी तार्किक होगा और इतना बुरा नहीं होगा।
किसी भी मामले में, उपयोग की जाने वाली प्रोग्रामिंग भाषा की परवाह किए बिना, सलाह समान होगी: यदि संभव हो, तो विधि ओवरलोडिंग और पुनर्वितरण मिश्रण नहीं करना बेहतर है (याद रखें कि तीन काफी लोकप्रिय प्रोग्रामिंग भाषाओं में हमें किस तरह का व्यवहार चिड़ियाघर मिला)।