2013-04-19 8 views
10

मेरे पास एक कक्षा है जो TObject से निकलती है, अगर मैं मूल विधि को कॉल नहीं करता, तो क्या यह बुरा है? मैं पूछता हूं क्योंकि TObject.Create/Destroy पर देखते हुए, वे कुछ भी नहीं करते हैं।क्या यह TObject से प्राप्त करते समय बेस विधि को कॉल करने की आवश्यकता है?

यही कारण है कि हम उन्हें ओवरराइड/एक्सपोज़ करते हैं।

कोई कोड उदाहरण नहीं है, मैं बस यह सुनिश्चित करना चाहता हूं।

उत्तर

17

सबसे आम व्यवहार inherited पर कॉल करना है। इसलिए यदि मैं स्पष्ट रूप से वंचित व्यवहार नहीं चाहता हूं, तो मैं inherited पर कॉल नहीं करता हूं। अन्यथा, मैं करता हूँ। यदि विरासत में व्यवहार TObject.Create/Destroy जैसा नो-ऑप है, तो भी मैं inherited पर कॉल करता हूं।

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

मुझे पता है कि कुछ लेखक को TObject से प्राप्त करते समय कोड लिखते हैं, क्योंकि वे जानते हैं कि TObject में कार्यान्वयन कुछ भी नहीं करता है। मुझे वह पसंद नहीं है और मेरे लिए यह करना एक गलती है। TObject के कार्यान्वयन विवरण व्युत्पन्न कक्षाओं में लीक नहीं होना चाहिए।

मुझे पूरा यकीन है कि TObject.Create/Destroy हमेशा नो-ऑप्स नहीं होगा। अगर एम्बरकेडेरो ने बदल दिया तो इतना कोड टूट जाएगा। लेकिन आपकी कक्षाओं में से एक के बारे में क्या। मान लें कि आपके पास TObject से ली गई कक्षा है। और फिर आप एक और वर्ग है कि से ली गई है:

constructor TMyClass2.Create; 
begin 
    // no need to call inherited, it's a no-op 
    FMyObj := TBlahBlah.Create; 
end; 

फिर एक दिन तुम क्या करने TMyClass1 निर्माता संशोधित:

TMyClass1 = class 
    .... 
end; 

TMyClass2 = class(TMyClass) 
    .... 
end; 

आप TMyClass1 के लिए कोई निर्माता और कहा कि इस तरह दिखता है TMyClass2 के लिए एक निर्माता है कुछ कुछ। अब TClass2 टूटा हुआ है। इसलिए, मैं कभी भी inherited पर कॉल नहीं छोड़ूंगा क्योंकि वह कॉल कुछ भी नहीं करता है।

सामान्य उदाहरण विधियों की स्थिति थोड़ा अलग है। यह अधिक व्यावहारिक है कि आप बेस क्लास कार्यान्वयन को अनदेखा करना चाहते हैं और एक नया नया कार्यान्वयन प्रदान करना चाहते हैं। लेकिन इस बात के आधार पर फैसला लें कि व्युत्पन्न वर्ग क्या करना चाहता है इसके बजाए सुपर क्लास के पास विधि के लिए खाली कार्यान्वयन है या नहीं।

+0

+1 'कार्यान्वयन विवरण' भाग के लिए। दरअसल, आरटीएल का कुछ भविष्य संस्करण वास्तव में इन खाली तरीकों में कुछ महत्वपूर्ण कोड डालने का फैसला कर सकता है। –

4

यदि आप पूर्वजों के कोड को निष्पादित करना चाहते हैं तो आपको केवल inherited पर कॉल करने की आवश्यकता है। Sometimtes आपको उस कोड की आवश्यकता है, कभी-कभी आप नहीं करते हैं। आप सशर्तयों का उपयोग भी कर सकते हैं और inherited पर कॉल कर सकते हैं, अगर कुछ शर्त पूरी हो जाती है, और आप चुन सकते हैं जब ऐसा करने के लिए (विधि की शुरुआत, विधि का अंत, ...)।

इसलिए, यह सब स्थिति पर निर्भर करता है।

Here's एक उदाहरण।

+0

मैं व्यक्तिगत रूप से अंत में यह करना है, खासकर अगर मैं TThread वंश। –

+5

आप इसे अंत में कर कि अगर एक नाशक में उदाहरण के लिए, करने के लिए सही बात है। और शुरुआत में अगर यह करने के लिए सही बात है, उदाहरण के लिए एक निर्माता में। और इसी तरह, आप कुछ उदाहरण विधियों के लिए विधि के बीच में ऐसा कर सकते हैं। आप 'TThread' से उतरना है, वहाँ आखिरी बात है कि आप अपने निर्माता में क्या रूप में विरासत में मिला निर्माता कॉल करने के लिए आवश्यकता नहीं है। मुझे लगता है कि आप गलती से सोच रहे हैं कि विरासत वाले कन्स्ट्रक्टर धागे को निष्पादित करना शुरू कर देता है। ऐसा नहीं होता। यह 'बाद के निर्माण' में होता है। –

0

भले ही TObject की बनाएं/नष्ट करें विधियां वर्तमान संस्करण में कुछ भी नहीं करती हैं, तो वे कुछ भविष्य के संस्करण (संभवतः, लेकिन फिर भी हो सकती हैं) में कुछ भी नहीं कर सकते हैं। तो क्या यह अभी आपके लिए जरूरी है?नहीं, क्योंकि यह कुछ भी पूरा नहीं करेगा, लेकिन केवल इसलिए कि वर्तमान माता-पिता कोई कार्यक्षमता नहीं जोड़ता है।

आप अपने वंशज वस्तुओं हमेशा अपने माता-पिता के लिए कार्यक्षमता जोड़ने के लिए चाहते हैं, तो यह शायद एक अच्छा विचार लगातार inherited कॉल करने के लिए किया जाएगा।

संबंधित मुद्दे

 संबंधित मुद्दे