2010-10-07 4 views
21

सैद्धांतिक प्रश्न के लिए समय मैंने अभी भाग लिया।आंशिक रूप से एक चाइल्ड क्लास में वर्चुअल ऑटो-प्रॉपर्टी को ओवरराइड करना

निम्नलिखित कोड वैध है और संकलित:

public class Parent 
{ 
    public virtual object TestProperty { get; set; } 
} 

public class Child : Parent 
{ 
    private string _testValue = "Hello World!"; 

    public override object TestProperty 
    { 
     get { return _testValue; } 
    } 
} 

public class Consumer 
{ 
    Parent p = new Child(); 

    public Consumer(){ p.TestProperty = 3; } 
} 

मेरा प्रश्न है:

क्यों सी # मुझे आंशिक रूप से एक बच्चे में TestProperty ऑटो संपत्ति ओवरराइड करने के लिए जब यह करने के लिए आंशिक रूप से अप्रत्याशित व्यवहार की ओर जाता है की अनुमति नहीं है ? क्या कोई व्यावहारिक अनुप्रयोग है?

मुझे माता-पिता के सेटटर का उपयोग करके टेस्टप्रोपर्टी का मान सेट करने की अनुमति है (मैंने आईएल उत्पन्न होने की जांच की है और सेटटर अभी भी मूल वर्ग में बैकिंग ऑब्जेक्ट सेट कर रहा है) भले ही मूल्य जनता के लिए उपलब्ध न हो।

+1

दिलचस्प सवाल! –

+2

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

+2

@ डेव - बहुत सच है। मैं बस यह सुनिश्चित करना चाहता हूं कि, इस मामले में, हथौड़ा के साथ मेरे अंगूठे को तोड़ने से कुछ उद्देश्य नहीं मिलते हैं जिन्हें मैं नहीं देख रहा हूं। –

उत्तर

12

यह व्यवहार सी # में गैर-ऑटो-लागू गुणों के अनुरूप है। आभासी संपत्ति के लिए केवल एक प्राप्त या सेट विधि को ओवरराइड करना हमेशा संभव रहा है। इसलिए एक ऑटो-लागू संपत्ति के साथ असंभव बनाना एक अनावश्यक असंगतता पैदा करेगा।

उदाहरण के लिए, निम्नलिखित

class A 
{ 
    public virtual int P1 
    { 
     get { return 42; } 
     set { } 
    } 
} 

class B : A 
{ 
    public override int P1 
    { 
     get { return 18; } 
    } 
} 
+0

पर्याप्त मेला। सवाल, तब, ऑटो-गुणों तक ही सीमित नहीं है। हालांकि व्यावहारिक अनुप्रयोग पर अभी भी थोड़ा अस्पष्ट है। अगर मैं अपनी पूरी संपत्ति को एक इकाई के रूप में घोषित कर रहा हूं और वह इकाई एक प्राप्त और सेट से बना है ... मैं एक को ओवरराइड क्यों करना चाहूंगा और दूसरे को संभावित भ्रमित व्यवहार से छोड़ दूंगा? –

+0

@ जस्टिन, संपत्ति के प्राप्त और सेट भाग मौलिक रूप से अलग-अलग तरीके हैं, इसलिए यह समझ में आता है कि उन्हें स्वतंत्र रूप से ओवरराइड किया जा सकता है। आप शायद क्यों चाहते हैं कि मैं गेटर में सेटर या कैशिंग व्यवहार में अतिरिक्त सत्यापन जोड़ना चाहता हूं लेकिन दूसरे के लिए डिफ़ॉल्ट व्यवहार रखना चाहता हूं। मुझे यकीन है कि यह – JaredPar

+1

@JaredPar करने के लिए कई वैध उपयोग मामले हैं - मैं समझता हूं कि वे मूल रूप से अलग-अलग तरीके हैं, लेकिन तर्कसंगत रूप से दोनों मेरे दिमाग में मिलते हैं। भाषा डिज़ाइन के संदर्भ में, हालांकि, दोनों को ओवरराइड करने की आवश्यकता क्यों नहीं है और फिर यदि आप मौजूदा कार्यक्षमता को रखना चाहते हैं तो आप बस वापसी आधार पर कॉल करें। टेस्टप्रोपर्टी() ;? (शायद यही कारण है कि मैं भाषाओं को डिजाइन करने के लिए कट नहीं हूं) –

1

यह एक सेटर के लिए कोई मतलब नहीं है, हालांकि कानूनी है? यदि आप आंशिक रूप से केवल सेटटर को ओवरराइड करते हैं, तो यह उपयोगी हो सकता है ताकि आप उस घटना का जवाब दे सकें, base.TestProperty = value पर कॉल करने के अलावा, गेटर के बॉयलरप्लेट ओवरराइड से परेशान किए बिना।

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