अमूर्त वर्ग कैसे बनाते हैं, लेकिन आंतरिक रूप से

Question

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

आपकी मदद की सराहना करें!

Answer 1

आप आंतरिक और सार्वजनिक रूप वर्ग खुद के रूप में निर्माता घोषित करने के लिए सक्षम होना चाहिए। यह आपको चाहिए (मुझे लगता है) आपको जो चाहिए वो दे।

Answer 2

आंतरिक कन्स्ट्रक्टर।

Answer 3

एक internal निर्माता इस मुद्दे को हल नहीं करना चाहिए? इस तरह केवल आपकी असेंबली उदाहरण बना सकती है, लेकिन उपयोगकर्ता अभी भी प्रतिबंधों के बिना उदाहरणों का उपयोग कर सकते हैं।

Answer 4

बस कक्षा के आंतरिक निर्माता का निर्माण करें?

Answer 5

तुम हमेशा निर्माता पर विभिन्न संशोधक का उपयोग करके उदाहरण निर्माण को नियंत्रित कर सकते हैं:

public class MyClass 
{ 
    internal MyClass() 
    { 
    } 
} 

अब कोई भी अपने वर्ग का दृष्टांत सकते हैं, लेकिन वे सामान्य की तरह इसके साथ काम कर सकते हैं अगर आप उन्हें एक उदाहरण देते हैं।

Answer 6

जैसा कि कई अन्य लोगों ने बताया है कि आप सार्वजनिक कक्षा में आंतरिक कन्स्ट्रक्टर रख सकते हैं।

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

Answer 7

एक आंतरिक scoped निर्माता का उपयोग करके आप एक ही विधानसभा या किसी अन्य विधानसभा के भीतर उपवर्गों बनाने के लिए करने के लिए जो आप आंतरिक दिखाई दिया है की अनुमति देगा। यह अन्य असेंबली में उप-वर्गों के निर्माण को रोक देगा, हालांकि, क्योंकि किसी अन्य वर्ग से प्राप्त प्रत्येक वर्ग को बेस क्लास पर एक कन्स्ट्रक्टर को कॉल करने की आवश्यकता होती है। यदि आपका कन्स्ट्रक्टर इसके दायरे के आधार पर उपलब्ध नहीं है तो यह आपके वर्ग से प्राप्त होने से रोक देगा।

आम तौर पर, मैं सोच इस तरह की है, हालांकि पसंद नहीं है। एक डेवलपर के रूप में यह वास्तव में परेशान करने के लिए परेशान है कि एक एपीआई का डेवलपर सोच रहा है कि वह इस बारे में सबकुछ जानता है कि मैं इसका उपयोग कैसे करना चाहता हूं। हां, अगर आपको जरूरी है तो कार्यान्वयन के आंतरिक विवरण छुपाएं, लेकिन कृपया मुझे जो कुछ चाहिए (और आपने सोचा नहीं है) करने के लिए एपीआई का विस्तार करने की अनुमति दें और मुझे ऐसा करने के लिए हुप्स के माध्यम से कूद न दें।

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

Answer 8

मुझे लगता है कि क्या आप चाहते हैं एक protected निर्माता के साथ एक public वर्ग और एक internal कारखाने विधि है:

public class MyClassWhichIsAbstractExceptForMe 
{ 
    // Allow derived classes but prevent public construction. 
    protected MyClassWhichIsAbstractExceptForMe() 
    { 
    } 

    // Allow internal construction 
    internal static MyClassWhichIsAbstractExceptForMe Create() 
    { 
     return new MyClassWhichIsAbstractExceptForMe(); 
    } 
} 

मैं भी धीरे एक डिजाइन समीक्षा सलाह देते हैं। यह काफी अजीब लगता है, जैसा कि दूसरों ने इंगित किया है।