क्या सी # कक्षा स्वयं के उदाहरण उत्पन्न कर सकती है?

Question

मेरे पास एक कक्षा है जो कॉलरेट प्रकार को परिभाषित करती है। मुझे फ़ाइल से डेटा पढ़ने के द्वारा मेरी कक्षा के कई उदाहरण बनाने की क्षमता जोड़ने की आवश्यकता है।

मैंने अपनी कक्षा कॉलरेट में एक स्थिर विधि जोड़ा जो List<CallRate> देता है। क्या कक्षा के लिए अपने स्वयं के रचनाकारों को बुलाकर खुद के नए उदाहरण उत्पन्न करना ठीक है? यह काम करता है, मुझे आश्चर्य है कि यह करना उचित बात है या नहीं।

List<CallRates> cr = CallRates.ProcessCallsFile(file); 

Answer 1

स्थैतिक विधि से स्वयं के ऑब्जेक्ट प्राप्त करने के लिए यह बिल्कुल ठीक है।

उदा।

डॉट नेट पुस्तकालयों में से एक के रूप में तुमने किया था एक ही बात करता है,

XmlReadrer reader = XmlReader.Create(filepathString); 

Answer 2

ज़रूर यह ठीक है, यहां तक ​​कि कुछ मामलों में प्रोत्साहित किया। कई design patterns that deal with object creation हैं, और उनमें से कुछ केवल वही करते हैं जो आप वर्णन कर रहे हैं।

Answer 3

मुझे ठीक लगता है। अन्य भाषाओं में आप शायद एक समारोह लिखेंगे, लेकिन सी # जैसी भाषा में, स्थैतिक विधियां उस भूमिका को उठाती हैं।

Answer 4

यह ठीक है। जो आपने अभी बनाया है वह एक साधारण फैक्ट्री विधि की तरह है। आपके पास एक स्थिर विधि है जो एक प्रकार का वैध उदाहरण बनाता है। असल में आपकी विधि को स्थैतिक भी नहीं होना चाहिए और आपके पास अभी भी एक वैध कोड है। एक डिज़ाइन पैटर्न (प्रोटोटाइप) है जो किसी मौजूदा ऑब्जेक्ट से एक नई मान्य ऑब्जेक्ट बनाता है। http://www.dofactory.com/Patterns/PatternPrototype.aspx पर विवरण देखें।

Answer 5

निश्चित रूप से, साधारण पार्सिंग (या समान) परिदृश्यों के लिए - मैं वास्तव में factory method कक्षा का हिस्सा बनना पसंद करता हूं। हां - यह SRP तोड़ता है, लेकिन यह KISS को पूरा करता है - इसलिए मैं इसे नेट जीत कहते हैं। बड़े ऐप्स, या अधिक जटिल पार्सिंग दिनचर्या के लिए - यह बाहरी कारखाना वर्ग होने के लिए अधिक समझ में आता है।

आपके विशेष मामले के लिए, शायद मैं एक फ़ाइल नाम के बजाय एक आईनेमेरेबल < स्ट्रिंग > में एक विधि पसंद करूंगा - जो आपको अभी भी पार्सिंग तर्क देगा, लेकिन आसान यूनिट परीक्षण और "पुन: उपयोग" की अनुमति देगा। कॉलर फ़ाइल को आसानी से पर्याप्त IENumerable में लपेट सकता है।

Answer 6

फैक्टरी विधियां अक्सर एक अच्छी डिजाइन होती हैं। जब मैं उन्हें सी # में लिखते हैं, मैं उन्हें 'नई' है, ताकि:

new MyClass() 

हो जाता है

MyClass.New() 

तुच्छता इसे इस तरह लागू हो जाता है:

class MyClass 
{ 
    public static MyClass New() 
    { 
     return new MyClass(); 
    } 
} 

ज्यादातर मैं इस जब करना वास्तव में कक्षा बनाने के लिए या null, या MyClass या उससे प्राप्त कुछ वापस लौटने के बारे में अतिरिक्त स्थितियां हैं या नहीं।

Answer 7

मैं कभी-कभी कन्स्ट्रक्टर ओवरलोडिंग के विकल्प के रूप में सार्वजनिक स्थैतिक विधियों का उपयोग करता हूं।

विशेष रूप से ऐसी परिस्थितियों में जहां पैरामीटर प्रकारों पर भरोसा करना अच्छा नहीं है, यह इंगित करने के लिए कि किस तरह के ऑब्जेक्ट निर्माण का इरादा है।

Answer 8

मैं स्थिर तरीके से वापसी के उदाहरण रखने के प्रशंसक हूं, जैसा ऊपर दिया गया है, ऊपर।

@Paul: उपरोक्त टिप्पणी को चिह्नित करने के लिए मत भूलना, जो आपको सबसे अच्छा जवाब मिल रहा है।

Answer 9

बस का कहना है

यह यह स्थिर विधि से है, निर्माता से नहीं है, "अपने स्वयं कंस्ट्रक्टर्स में से एक को फोन करके खुद के नए उदाहरणों उत्पन्न" अच्छा लगता है।

Answer 10

मैं आमतौर पर इसका उपयोग तब करता हूं जब मुझे कक्षा के तत्काल कार्यान्वयन की आवश्यकता होती है। उदाहरण के लिए

public class Car 
    { 
     public static Car RedExpensiveCar = new Car("Red", 250000); 

     public Car() 
     { 

     } 

     public Car(string color, int price) 
     { 
      Color = color; 
      Price = price; 
     } 

     public string Color { get; set; } 
     public int Price { get; set; } 
    } 

और इसके साथ में, मुझे अपने कोड में निर्माता पैरामीटर को याद रखने या लिखने की आवश्यकता नहीं है।

Car car = Car.RedExpensiveCar; 

Answer 11

मैं अक्सर पैरामीटर की वैधता की जांच करने के लिए इस पैटर्न का उपयोग करता हूं। यह एक कन्स्ट्रक्टर से अपवाद फेंकने के लिए दृढ़ता से निराश है। यह फैक्ट्री विधि से इतना बुरा नहीं है, या आप शून्य वापस करने का चयन कर सकते हैं।

Answer 12

यह करने के लिए यह पूरी तरह स्वीकार्य है। जब मैं करता हूं, तो मैं आम तौर पर कक्षा के लिए वास्तविक रचनाकार बनाता हूं ताकि यह स्पष्ट हो कि केवल उदाहरण बनाने के लिए स्थिर विधि के माध्यम से है।

यह उन मामलों में बहुत उपयोगी है जहां "निर्माण" हमेशा एक नया उदाहरण नहीं लौटा सकता है। उदाहरण के लिए, आप इसके बजाय पहले कैश किए गए ऑब्जेक्ट को वापस करना चाह सकते हैं।