इस लेख में मैं IEnumerable इंटरफ़ेस का उपयोग करने की समस्याओं के बारे में बात करना चाहता हूं। हम देखेंगे कि इस इंटरफ़ेस का उपयोग किन समस्याओं को ला सकता है जब इसे वास्तव में उपयोग करने की आवश्यकता होती है, और इसे कैसे बदलना है।

और मैं कुछ कोड उदाहरणों के साथ या बग की एक जोड़ी के साथ लेख शुरू करना चाहता था, जो मुझे वास्तविक परियोजनाओं में मिला।

समस्या के उदाहरण हैं

यहां पहला उदाहरण है - एक वास्तविक परियोजना से कोड, केवल नाम बदल दिए जाते हैं।

private IEnumerable<Account> GetAccountsByOrder(IEnumerable<Account> accounts, IEnumerable<OrderItem> orderItems) { var orderItemsWithQuotaOwners = _restsProvider.GetQuotaOwner(orderItems); return accounts.Where( q => orderItemsWithSourceQuotaOwners.Any(s => s.QuotaOwner == q.QuotaOwner && ... )); } 

यह प्रतीत नहीं होता कि जटिल कोड का टुकड़ा हमारे लिए काफी परेशानी लेकर आया है। यह सब GetQuotaOwner विधि के बारे में है। इसके अंदर, LINQ to SQL क्वेरी को निष्पादित किया जाता है, फिर LINQ पर संस्थाओं को एक प्रोजेक्शन बनाया जाता है और IEnumerable को लौटाया जाता है। परिणामस्वरूप, quotedAccounts की प्रत्येक पंक्ति के लिए हमें GetQuotaOwner विधि इंटर्नल्स का एक नया निष्पादन मिलता है। दिलचस्प बात यह है कि इस मामले में, रिसर्पर ने हमें खतरे के बारे में चेतावनी नहीं दी।

यह एक दूसरा उदाहरण है। यहाँ, हालाँकि, वास्तविक परियोजना का कोड नहीं है, लेकिन कोड और समस्या का विचार वास्तविक परियोजना से लिया गया है।

 class Foo { public string Value; } class Bar { public string Value; public int ACount; } static void Main() { Foo[] foo = new[] { new Foo { Value = "Abba" }, new Foo { Value = "Deep Purple" }, new Foo { Value = "Metallica" } }; var bar = foo.Select(x => new Bar { Value = x.Value, ACount = x.Value.Count(c => c == 'a' || c == 'A') }); Censure(bar); foreach (var one in bar) { Console.WriteLine(one.Value); } } private static void Censure(IEnumerable<Bar> bar) { foreach (var one in bar) { if (one.ACount > 1) { one.Value = "<censored>"; } } } 

यहाँ हम कुछ डेटा प्राप्त करते हैं, उनके प्रक्षेपण का निर्माण करते हैं और फिर उसे सेंसर करते हैं। और बड़े आश्चर्य के साथ हम देखते हैं कि जो डेटा सेंसर नहीं किया गया है वह स्क्रीन पर आता है ...

समस्या का कारण काफी सरल है - हम दो बार संग्रह पर पुनरावृति करते हैं, जिसका अर्थ है कि हमें बार वर्ग के उदाहरणों के दो स्वतंत्र संग्रह मिलते हैं।

यह स्पष्ट है कि कोड के इन दो टुकड़ों को ठीक करना मुश्किल नहीं है, बस ToArray जोड़ें। सवाल अलग है - हमने मौलिक रूप से क्या गलत किया और IEnumerable के साथ सही तरीके से कैसे काम किया जाए।

क्या सार IEnumerable

शुरू करने के लिए, IEnumerable को इस तरह समझें। तकनीकी विवरण में जाने के बिना, यह इंटरफ़ेस तत्वों के अनुक्रम को सार करता है। इसके अलावा, इस अनुक्रम के बारे में पूरी तरह से कुछ भी ज्ञात नहीं है: चाहे वह परिमित हो या अनंत, इस पर परिचालन की लागत क्या है।

यहाँ एक सरल उदाहरण है - var lines = File.ReadLines ("data.txt");

अब हम लाइनों के साथ क्या कर सकते हैं? ठीक है, अगर हम अपने कार्यक्रम के प्रदर्शन को मारना नहीं चाहते हैं, तो हम इस संग्रह पर दो बार पुनरावृत्ति नहीं कर सकते। मासूम कोड का मतलब है

  var lines = File.ReadLines("data.txt"); string lastLine = lines.ElementAt(lines.Count()); 

हमारे लिए वर्जित होना चाहिए।

और भी बुरा हो सकता है:

 class RandomStrings : IEnumerable<int> { Random _rnd = new Random(); public IEnumerator<int> GetEnumerator() { while (true) yield return _rnd.Next(); } } 

अब एक भी निर्दोष गणना () हमारे आवेदन को लटका देती है।

एक सरल निष्कर्ष इस प्रकार है: IEnumerable के साथ काम करना बहुत मुश्किल है यह मानकर कि यह अंदर बैठता है।

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

लेकिन वास्तविक कार्यक्रमों में, सबसे अधिक बार, प्रोग्रामर IEnumerable के संग्रह के रूप में सोचता है। उदाहरण के लिए, यहां तक ​​कि इस तरह के एक पैटर्न दिखाई दिया - IEnumerable की एक सुरक्षात्मक प्रतिलिपि। यानी कॉल करने की विधि की शुरुआत में ToArray () जब IEnumerable वहां आता है।

यही है, हम तुरंत कहते हैं - एक परिमित अनुक्रम हमारे पास आया है जो आसानी से स्मृति में फिट बैठता है। लेकिन जब हम संग्रह का मतलब है तो हम IEnumerable का उपयोग क्यों करते हैं?

यहाँ, हालाँकि, एक योग्य पाठक पूछ सकता है - संग्रह के साथ सही ढंग से काम करने का क्या मतलब है? संग्रह अलग-अलग हैं - एक लिंक की गई सूची भी एक संग्रह है, और ऊपर की शैली में एक लिंक की गई सूची के लिए अंतिम पंक्ति प्राप्त करना भी आम तौर पर बेहद अक्षम है (हालांकि निश्चित रूप से IEnumerable के मामले में उतना डरावना नहीं है, जहां इससे अधिक है। संग्रह काम की एक बड़ी राशि के साथ जुड़ा जा सकता है)।

इसलिए, यह अवधारणाओं को स्पष्ट करने और एक वेक्टर के बारे में बात करने के लायक है (.NET सूची में, अब से मैं इस संग्रह को एक शीट कहूंगा) या एक सरणी।

फिर हम वास्तव में अनुबंध के तहत कार्यक्रम कर सकते हैं - यदि IList पद्धति के इनपुट को पारित किया जाता है, तो हम एक शीट के रूप में काम करते हैं, यह जानते हुए कि एक मनमाना तत्व तक पहुंच और तत्वों की संख्या प्राप्त करना हे (1) है, और यदि IEnumerable हमारे पास आया है, तो हमें सही और सही तरीके से लागू करना होगा। उसके साथ प्रभावी काम करते हैं।

वापसी के मूल्य के साथ एक समान स्थिति - IEnumerable लौटते हुए, हम उपयोगकर्ता को बहुत अधिक जटिल कोड लिखने के लिए मजबूर करते हैं जो एक अनुक्रम के साथ काम करता है, न कि एक शीट के साथ।

LINQ

आईईएन में स्थिति IEnumerable के प्रभुत्व के साथ LINQ की शुरूआत के साथ बढ़ी। यदि इससे पहले कि आवेदन इस इंटरफ़ेस को जीवन में कुछ बार देख सकता था, अब कोई LINQ अनुरोध IEnumerable उत्पन्न करता है।

सवाल उठता है - ऐसे IEnumerable के साथ क्या करना है? आप एक चरम पर जा सकते हैं - तुरंत एक सरणी या सूची में परिवर्तित कर सकते हैं। इस दृष्टिकोण को जीवन का अधिकार है। यह पुन: पुनरावृत्ति के साथ कोई समस्या नहीं है। दूसरी ओर, कई अतिरिक्त सरणियां उत्पन्न की जा सकती हैं, जिन्हें तब कचरा कलेक्टर द्वारा एकत्र किया जाना है।

आप एक समझौता कर सकते हैं: विधि के अंदर IEnumerable के साथ काम करते हैं, केवल एरे या चादरें देते हैं। इस दृष्टिकोण का नुकसान यह है कि आपको IEnumerable (वास्तविक स्रोत में var ...) के प्रकारों के बारे में अधिक सावधान रहना होगा, उन पर बार-बार होने वाले पुनरावृत्तियों से बचना चाहिए, इस घटना में कि यह प्रदर्शन को प्रतिकूल रूप से प्रभावित कर सकता है। वैचारिक रूप से, यह दृष्टिकोण भी स्वीकार्य है - एक विधि के भीतर, हम अच्छी तरह से IEnumerable के इस विशेष उदाहरण की प्रकृति को जान सकते हैं और इसे शून्य में गोलाकार IEnumerable के रूप में इलाज करने का प्रयास नहीं कर सकते हैं।

एक संग्रह प्रकार का चयन

जैसा कि पहले ही उल्लेख किया गया है, तरीकों के बीच संग्रह को स्थानांतरित करने के लिए ICollection सबसे सफल प्रकार नहीं है। IEnumerable की तुलना में ICollection के एक मनमाना कार्यान्वयन के साथ काम करना थोड़ा आसान है।

आप IList का चयन कर सकते हैं, लेकिन IEnumerable की तुलना में इस इंटरफ़ेस में एक बहुत बड़ा ऋण है - यह आपको संग्रह संपादित करने की अनुमति देता है, जबकि 95% मामलों में संग्रह स्वयं पढ़ने योग्य वस्तुओं के रूप में होते हैं।

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

एक अन्य संभावना ReadOnlyCollection का उपयोग करना है। मैं तुरंत कहना चाहता हूं कि इस वर्ग का गलत नाम है। इसके एकमात्र निर्माता में निम्नलिखित हस्ताक्षर सार्वजनिक ReadOnlyCollection (IList सूची) है। यानी इसे ReadOnlyList कहना ज्यादा सही होगा। पहली नज़र में, हर जगह इस वर्ग का उपयोग करना बहुत सुविधाजनक नहीं हो सकता है, लेकिन अगर आप विस्तार लिखते हैं

 public ReadOnlyCollection<T> ToReadOnly(this IEnumerable<T> data) 

यह काम करने का विकल्प हो सकता है।

खैर, रूपरेखा 4.5 ने पहले ही इस समस्या को हल कर दिया है: यह IReadOnlyCollection और IReadOnlyList इंटरफेस का परिचय देता है। इसके अलावा, सूची इरिडोनेलीलिस्ट लागू करता है, अर्थात। लिख सकते हैं

 IReadOnlyList<Foo> Do(IReadOnlyList<Bar> bar) { return bar.Where(x => IsGood(x)).ToList(); } 

निष्कर्ष

हस्ताक्षर में IEnumerable विधियों का व्यापक उपयोग अनुबंधित प्रोग्रामिंग के सिद्धांतों का उल्लंघन करता है और त्रुटियों की ओर जाता है।

विधियों के बीच से गुजरने के लिए, आप केवल IEnumerable का उपयोग कर सकते हैं यदि आपको वास्तव में IEnumerable के साथ काम करने की आवश्यकता है, और नियमित संग्रह के साथ काम करना प्रभावी या असंभव नहीं होगा।

विधियों के बीच केवल-पढ़ने के संग्रह को स्थानांतरित करने के लिए, आप सरणियों, ReadOnlyCollection वर्ग और IReadOnlyList इंटरफ़ेस का उपयोग कर सकते हैं।

पुनश्च
इसी विषय पर हैबर पर एक और लेख है ।