2010-06-15 26 views
13

मैं मूल रूप से ऐसा करने के लिए इच्छुक हूँ:सामान्य पैरामीटर से कैसे प्राप्त किया जाए?

class UILockable<T> : T 
    where T : UIWidget 
{ 
} 

बहरहाल, यह काम नहीं करता। मैंने देखा है लोगों को सुझाव है कि आप ऐसा करते हैं कि:

class UILockable<T> 
    where T : UIWidget 
{ 
    private T _base; 
} 

यह मैं की आवश्यकता होगी प्रत्येक कार्य UILockable ओवरराइड करने के लिए की जरूरत है और इसे आगे टी करने के लिए यह असंभव है के बाद से टी UIWidget से निकाले जाते हैं और अद्वितीय सार/आभासी हो सकता है जाएगा अपने तरीके के तरीके।

क्या टी से आसानी से प्राप्त करने का कोई तरीका नहीं है?

+0

सामान्य इंटरफ़ेस को लागू करने के लिए सामान्य प्रकार को मजबूर करने पर विचार करें। आप नहीं जानते कि सटीक प्रकार टी क्या है, और यदि आप विशिष्ट तरीकों की तलाश में हैं जो किसी भी टी के पास हो या नहीं, तो यह काम नहीं करेगा। ऐसे सभी ऑब्जेक्ट्स को इलॉकबल लागू करें जो अनुबंधों की तरह उन विधियों को मजबूर करता है। – drharris

+1

यदि आपको अपने लॉकिंग तर्क को पूरा करने के लिए संरक्षित विधियों को ओवरराइड करने की आवश्यकता नहीं है, तो आप लॉकिंग सेवा ऑब्जेक्ट का उपयोग करके इसे फिर से डिज़ाइन कर सकते हैं जो आपके लॉकिंग तर्क के लिए उपयोग किए गए LockContext ऑब्जेक्ट्स के साथ UIWidget इंस्टेंस को जोड़ता है। मुझे नहीं लगता कि आप जो करने की कोशिश कर रहे हैं, उसके लिए विरासत एक अच्छा वैचारिक फिट है, क्योंकि आप आम तौर पर कार्यक्षमता बढ़ाने की कोशिश कर रहे हैं, एक ठोस 'इज-ए' रिश्ते को व्यक्त नहीं करते हैं। –

+0

संभावित प्रतिलिपि [एक बाधित जेनेरिक प्रकार पैरामीटर पर विरासत] (http://stackoverflow.com/questions/1420581/inheritance-on-a-constrained-generic-type-parameter) – joce

उत्तर

16

आप सामान्य प्रकार पैरामीटर से प्राप्त नहीं कर सकते हैं। सी # जेनेरिक सी ++ टेम्पलेट्स से बहुत अलग हैं। प्रकार पैरामीटर से विरासत में वर्ग को टाइप पैरामीटर के आधार पर एक पूरी तरह से अलग प्रतिनिधित्व होना आवश्यक है, जो .NET जेनरिक के साथ नहीं होता है। वे आईएल और देशी स्तर (सभी संदर्भ प्रकार तर्कों के लिए) में समान हैं।

3

नहीं, ऐसा नहीं है। हालांकि, मैं वास्तव में UIWidget से UILockable<T> इनहेरिट होने के खिलाफ अपने तर्क समझ में नहीं आता है और अपने T पर सभी कॉल अग्रेषित:

class UILockable<T> : UIWidget 
    where T : UIWidget 
{ 
    private readonly T t; 

    public void SomeMethod() 
    { 
     this.t.SomeMethod(); 
    } 
} 

आप T के UIWidget के कार्यान्वयन की बारीकियों के बारे में परवाह नहीं है - केवल यह है कि UIWidget का कार्यान्वयन है।

+3

मुझे लगता है कि वह क्या कह रहा है कि यदि आप ऐसा करने के लिए, 'UI' की कोई भी विधि जो 'UIWidget' द्वारा निर्दिष्ट नहीं हैं, पहुंच योग्य नहीं होगी। –

+1

इस मामले में, आपको अधिक सामान्य बाधाओं को जोड़ने की आवश्यकता होगी जैसे कि टी UIUidget को बढ़ाता है और कुछ इंटरफेस भी लागू करता है। –

3

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

तो क्या आप यह घोषणा करना चाहते हैं कि Unlockable सब कुछ है कि UIWidget के समान है के समान है, लेकिन क्योंकि प्रकार समानता सकर्मक नहीं है कि असंभव है (यानी अगर बीके समान है एक और सी समान है आप नहीं कह सकते हैं बीसी के समान है)।

+0

@Robert यह क्यों उत्तर नहीं है? – AgentFire

+1

@AgentFire: क्योंकि यह आवश्यक बिंदु को अनदेखा करता है - 'अनलॉक करने योग्य ' 'UI 'के समान होगा,' UIWidget' के अन्य उप-वर्गों के समान नहीं होगा, और यह 'टी' से व्यवहार को विरासत में लाने के गुण के समान होगा। –

0

आप जेनेरिक प्रकार तर्क से उत्तराधिकारी नहीं हो सकते हैं। सी # कड़ाई से टाइप की गई भाषा है। सभी प्रकार और विरासत पदानुक्रम संकलन समय पर जाना जाना चाहिए। .NET जेनेरिक सी ++ टेम्पलेट्स से अलग तरीके हैं।

और जब आप सुनिश्चित हैं कि तर्क टी टाइप प्रकार UIWidget होने जा रहा है तो UIWidget से क्यों उत्तराधिकारी नहीं है। क्या इसे कभी भी अनुमति दी जानी चाहिए [मान लीजिए, मान लीजिए, मुझे पता है कि यह कभी भी संभव नहीं होगा] आप टी से अपनी कक्षा को विरासत में प्राप्त करके क्या हासिल करेंगे जो पहले से ही UIWidget प्रकार है। डिज़ाइन समय पर, आप केवल UIWidget के विरुद्ध कोड करेंगे, इसलिए UIWidget से सीधे क्यों नहीं प्राप्त करें।

+0

क्यों 'UIWidget' से सीधे उत्तराधिकारी नहीं है? * Mixins *। सिर्फ इसलिए कि मिश्रण केवल 'UIWidget' द्वारा प्रदान किए गए आवश्यक इंटरफ़ेस का उपयोग कर सकता है, इसका मतलब यह नहीं है कि उपभोक्ता एक ही ऑब्जेक्ट पर मिश्रित व्यवहार और कुछ और विशेष विजेट व्यवहार * नहीं लेना चाहता। –

+0

दृढ़ता से स्थाई रूप से टाइप किया गया और इस विरासत को मना कर पूरी तरह से ऑर्थोगोनल हैं। – Puppy

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

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