क्या मैं subclasses को सार बनाने के बिना किसी विधि को ओवरराइड करने के लिए मजबूर कर सकता हूं?

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

क्या विधियों को चिह्नित करने का कोई तरीका है ताकि उन्हें सबक्लास द्वारा लागू किया जाना चाहिए, उन्हें सार के रूप में चिह्नित किए बिना?

स्रोत

2008-10-27 Simon

आपने डिजाइनर में बेस क्लास को कैसे डिजाइन किया है? –

ठीक है आप #if से जुड़े कुछ वास्तव में गन्दा कोड कर सकते हैं - यानी DEBUG में यह आभासी (डिजाइनर के लिए) है, लेकिन RELEASE में यह सार है। हालांकि, बनाए रखने के लिए एक असली दर्द।

लेकिन इसके अलावा: मूल रूप से, नहीं। आप डिजाइनर समर्थन चाहते हैं यह, सार नहीं किया जा सकता है ताकि आप "आभासी" (संभवतः आधार विधि एक NotImplementedException फेंकने के साथ) के साथ छोड़ दिया जाता है।

बेशक, आपके यूनिट परीक्षण जांचेंगे कि विधियां लागू की गई हैं, हां? ;-p

वास्तव में, यह शायद जेनरिक के माध्यम से परीक्षण करने के लिए काफी आसान हो सकता है - यानी फार्म की एक सामान्य परीक्षा पद्धति है:

[Test] 
public void TestFoo() { 
    ActualTest<Foo>(); 
} 
[Test] 
public void TestBar() { 
    ActualTest<Bar>(); 
} 

static void ActualTest<T>() where T : SomeBaseClass, new() { 
    T obj = new T(); 
    Assert.blah something involving obj 
}

स्रोत

2008-10-27 09:32:54

मैं जानता हूँ कि इसकी काफी नहीं आप के बाद क्या कर रहे हैं, लेकिन आप कर सकते हैं बेस क्लास में आपके सभी स्टब्स NotImplementedException फेंक देते हैं। फिर यदि आपके किसी भी उप-वर्ग ने उन्हें ओवरराइड नहीं किया है तो बेसबॉल में विधि कहने पर आपको रनटाइम अपवाद मिलेगा।

स्रोत

2008-10-27 10:15:16

हाँ, मैंने यह किया है, लेकिन मुझे संकलन-समय अपवाद चाहिए। – Simon

घटक वर्ग में "डिज़ाइनमोड" नामक एक बूलियन प्रॉपर्टी होती है जो बहुत आसान है जब आप अपने कोड को रनटाइम की तुलना में डिज़ाइनर में अलग-अलग व्यवहार करना चाहते हैं। इस मामले में कुछ उपयोग हो सकता है।

स्रोत

2008-10-27 15:20:32

आप अपनी कक्षा में कार्यान्वयन मुहावरे के संदर्भ का उपयोग कर सकते हैं।

public class DesignerHappy 
{ 
    private ADesignerHappyImp imp_; 

    public int MyMethod() 
    { 
     return imp_.MyMethod()  
    } 

    public int MyProperty 
    { 
     get { return imp_.MyProperty; } 
     set { imp_.MyProperty = value; } 
    } 
} 

public abstract class ADesignerHappyImp 
{ 
    public abstract int MyMethod(); 
    public int MyProperty {get; set;} 
}

DesignerHappy बस आप चाहते हैं इंटरफेस लेकिन आगे कार्यान्वयन वस्तु के लिए सभी कॉल उजागर करता है। आप उप-वर्गीकरण ADesignerHappyImp द्वारा व्यवहार का विस्तार करते हैं, जो आपको सभी अमूर्त सदस्यों को लागू करने के लिए मजबूर करता है।

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

स्रोत

2008-10-27 16:01:34 Curro

एक सामान्य नियम के रूप में, यदि किसी भाषा में ऐसा करने का कोई तरीका नहीं है जिसका आम तौर पर मतलब है कि ऐसा करने के लिए एक अच्छा वैचारिक कारण नहीं है।

कभी-कभी यह भाषा डिजाइनरों की गलती होगी - लेकिन अक्सर नहीं। आम तौर पर मुझे लगता है कि वे भाषा डिजाइन के बारे में अधिक जानते हैं ;-)

इस मामले में आप एक संकलित समय अपवाद (बल्कि एक रन टाइम एक) फेंकने के लिए एक अनदेखा वर्चुअल विधि चाहते हैं। मूल रूप से तब एक सार विधि।

वर्चुअल विधियों को सार तत्वों की तरह व्यवहार करना सिर्फ आपके लिए लाइन के नीचे भ्रम की दुनिया बनाने जा रहा है।

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

यदि आप वर्णन कर रहे हैं तो मुझे लगता है कि आपके पास क्लास डिज़ाइनर का उपयोग न करने का तर्क है, न कि आपके कोड को हैक करने का तर्क।

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

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

स्रोत

2008-10-27 17:11:04 Keith

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

@ टिम - मैं वास्तव में यह नहीं कह रहा था कि यह वैध नहीं था, मेरा मुद्दा यह था कि उपकरण के अनुरूप कोड को हैक करना आखिरी उपाय होना चाहिए। इस मामले में मुझे लगता है कि सबसे अच्छा समाधान वास्तव में स्वीकार्य उत्तर में है - वर्चुअल सदस्यों और यूनिट परीक्षण कोड में 'NotImplementedException' फेंक दें। – Keith

ध्यान दें कि "DesignMode" कन्स्ट्रक्टर में सेट नहीं है। VS पार्स को InitializeComponents() विधि के बाद सेट किया गया है।

स्रोत

2008-11-20 16:36:21

एक उदाहरण के रूप एमएस उपयोग करने के लिए ...

माइक्रोसॉफ्ट सिल्वरलाइट में उपयोगकर्ता नियंत्रण टेम्पलेट के साथ करता है। #if पूरी तरह से स्वीकार्य है और यह संदिग्ध है कि टूलींग जल्द ही इसके आसपास काम करेगी। आईएमएचओ

स्रोत

2011-10-19 02:26:29 Roger

उद्धरण की आवश्यकता है! – manas

क्या मैं subclasses को सार बनाने के बिना किसी विधि को ओवरराइड करने के लिए मजबूर कर सकता हूं?

उत्तर

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