GetEnumerator() IENumerator से एक अलग इंटरफ़ेस में संग्रहीत क्यों किया गया था?

Question

मैं सोच रहा था कि GetEnumerator() विधि को IENumerator से क्यों निकाल दिया गया था और IENumerable में रखा गया था। ऐसा लगता है कि यह IENumerator में सभी गणक विधियों को रखने के लिए और अधिक समझदारी होगी।

धन्यवाद,

स्कॉट

Answer 1

खुद से पूछें "कल्पना करें कि यह सच था"।

यदि सभी गणना विधियां एक ही इंटरफेस पर थीं, तो दो कॉलर्स एक ही सूची में एक ही सूची को कैसे समझा सकते हैं?

दो इंटरफेस हैं क्योंकि कोई कहता है, "आप मुझे गिन सकते हैं," जबकि दूसरा कहता है, "यहां एक ऐसी वस्तु है जो किसी दिए गए गणित कार्य का ट्रैक रखती है।"

IEnumerable इंटरफ़ेस एक ऐसा कारखाना है जो आपको जितनी चाहें IEnumerator ऑब्जेक्ट्स बनाता है। कैसे और जब उन गणकों का उपयोग किया जाता है उपभोक्ता तक।

Answer 2

IEnumerable का तात्पर्य है कि वस्तु एक संग्रह या डेटा जो एक रैखिक फैशन में अधिक दोहराया जा सकता है का स्रोत है। IEnumerator वास्तविक कार्यान्वयन के लिए इंटरफेस है जो पुनरावृत्ति करता है।

Answer 3

क्योंकि "आईन्यूमेरेबल" कहता है "आओ, मुझे बताएं" (और फिर आप कहते हैं- कैसे, मुझे गणक दें), हालांकि "आईन्यूमेरेटर" कहता है "मैं आपके संग्रह की गणना कर सकता हूं!" और आपके पास पहले से ही है, आपको और भी प्राप्त करने की आवश्यकता नहीं है।

Answer 4

क्योंकि अक्सर गणना करने वाली चीज केवल गणना की जाने वाली चीज़ से संबंधित है (अगर बिल्कुल)। यदि IENumerable और IENumerator एक ही इंटरफ़ेस थे, तो उन्हें साझा नहीं किया जा सका, या आपको GetEnumerator पर कुछ अवांछित तर्क होना होगा जिसने आपको ऑब्जेक्ट में गणना करने की अनुमति दी है। उन्हें विभाजित करने से गणना के आधारभूत संरचना को विभिन्न प्रकारों में संभावित रूप से साझा किया जा सकता है।

Answer 5

आपको यहां बहुत अच्छे जवाब मिल गए हैं। बस कुछ जोर। एक गणक राज्य रखता है, यह संग्रहित होने वाले संग्रह में वर्तमान वस्तु का ट्रैक रखता है। IENumerator.Current के माध्यम से उपलब्ध है। और यह जानता है कि उस स्थिति को कैसे बदला जाए, IENumerator.MoveNext()। राज्य को रखने के लिए एक अलग वस्तु की आवश्यकता होती है जो राज्य को स्टोर करती है। उस स्थिति को संग्रह ऑब्जेक्ट के अंदर आसानी से संग्रहीत नहीं किया जा सकता है क्योंकि केवल एक संग्रह वस्तु है लेकिन एक से अधिक गणक हो सकते हैं।

मैंने वाक्यांश को "आसानी से" इस्तेमाल किया क्योंकि वास्तव में संग्रह के लिए अपने गणक का ट्रैक रखना संभव है। आखिरकार, यह संग्रह वर्ग 'GetEnumerator() विधि के लिए एक कॉल था जो इटेटरेटर लौटा। .NET ढांचे में एक संग्रह वर्ग है जो यह करता है, माइक्रोसॉफ्ट। VisualBasic.Collection। इसे अपने संग्रह वर्ग के लिए एक वीबी 6 अनुबंध लागू करने की आवश्यकता थी और यह अनुबंध निर्दिष्ट करता है कि गणना के दौरान संग्रह को बदलना कानूनी है। जिसका अर्थ यह है कि जब संग्रह संशोधित होता है, तो इसे बनाए गए सभी इटरेटर ऑब्जेक्ट्स के साथ कुछ उचित करने की आवश्यकता होती है।

वे एक बहुत अच्छी चाल के साथ आए, वीक रेफरेंस इस से प्रेरित हो सकता है। परावर्तक द्वारा दिखाए गए कोड पर एक नज़र डालें। प्रेरणादायक चीजें संग्रह कक्षाओं में कुछ और खोएं और "संस्करण" ढूंढें। बहुत बढ़िया चाल

Answer 6

minlinq पर बार्ट डी स्मेट की पोस्ट पढ़ने के बाद मुझे अब विश्वास नहीं है कि दो इंटरफेस को विभाजित करने की सख्ती से आवश्यकता है।

उदाहरण के लिए - ऊपर के लिंक में, IEnumerable/IEnumerator एक भी विधि इंटरफ़ेस

Func<Func<Option<T>>> 

और कुछ बुनियादी कार्यान्वयन

public static class FEnumerable 
{ 
    public static Func<Func<Option<T>>> Empty<T>() 
    { 
     return() =>() => new Option<T>.None(); 
    } 

    public static Func<Func<Option<T>>> Return<T>(T value) 
    { 
     return() => 
     { 
      int i = 0; 
      return() => 
       i++ == 0 
       ? (Option<T>)new Option<T>.Some(value) 
       : (Option<T>)new Option<T>.None(); 
     }; 
    } 

    ... 

} 

public static Func<Func<Option<T>>> Where<T>(this Func<Func<Option<T>>> source, Func<T, bool> filter) 
{ 
    return source.Bind(t => filter(t) ? FEnumerable.Return(t) : FEnumerable.Empty<T>()); 
}