2011-02-19 9 views
5

मैंने देखा है कि कई इटरेटर या डेटा पाठक केवल DataReader, XmlReader, IEnumerator, किसी भी (आपको विचार मिला) जैसे आगे हैं।ट्रैवर्सल केवल अधिकतर समय क्यों आगे बढ़ता है?

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


तो मेरी प्रश्न हैं:

  • आगे केवल सबसे डाटा-Iterators क्यों हैं

  • मैं गलत एक पिछड़े traversable इटरेटर/डेटा पाठक बनाने में हूँ। यदि नहीं, तो फ्रेमवर्क में इसके अंतर्निहित डेटा इटरेटर्स के लिए ऐसा समर्थन क्यों नहीं है।

  • हम किसी भी गंभीर प्रदर्शन दोष या उसके ऐसी सुविधा सिर्फ नहीं माना एक अच्छे डिजाइन के लिए है।


यह सवाल मुझे शुरू से ही एक बहुत bugged है लेकिन कभी भी कोई संतोषजनक जवाब मिल गया तो मैं यह पूछ रहा हूँ है.मुझे विश्वास है कि कई डेवलपर्स मुझसे सहमत हो सकता है कि पिछड़े traversing कभी कभी उपयोगी हो सकता है है ।

उत्तर

9

"आगे केवल" है:

  • अधिकांश उपभोक्ताओं
  • लागू करने के लिए सरल लिए सबसे अधिक उपयोग, इसलिए को सबसे अधिक संभावना हो सबसे उत्पादकों
  • केवल एक चीज हम द्वारा कार्यान्वित अगर हम मानते हैं कि हम स्मृति में सभी डेटा बफर नहीं करना चाहते हैं
  • आसानी से यादृच्छिक पहुंच (मध्यम आकार के डेटा के लिए)

उदाहरण के लिए, यदि आप किसी डेटाबेस, नेटवर्क स्ट्रीम आदि से डेटा पढ़ रहे हैं, तो आप केवल "आगे" की गारंटी दे सकते हैं। हम निश्चित रूप से सभी डेटा को मनमाने ढंग से बफर नहीं करना चाहते हैं - यह विशाल संभावित रूप से हो सकता है।

यदि ग्राहक सोचता है कि उनके पास डेटा की मात्रा है, तो वे स्मृति में बफर करने और यादृच्छिक पहुंच की अनुमति देने के लिए हमेशा ToList() आदि पर कॉल कर सकते हैं।

उदाहरण के लिए, इस पूरी तरह से वैध अनुक्रम पर विचार करें:

public static IEnumerable<int> LotsOfData() { 
    var random = new Random(); 
    while(true) yield return random.Next(); 
} 
  • यह बफरिंग के बिना वापस नहीं लिया जा सकता है
  • यह लंबाई में अनंत है, इसलिए बफ़र नहीं किया जा सकता

जाहिर है कि उदाहरण थोड़ा असंभव है, लेकिन सॉकेट, डेटाबेस, या यहां तक ​​कि एक बड़ी फ़ाइल से पढ़ना - ess हो सकता है एक ही परिदृश्य में

+0

आप उस परिदृश्य में निश्चित रूप से सही हैं लेकिन एक बड़ी फ़ाइल से डेटा पढ़ने के दौरान यदि हम थोड़ा पिछड़ा पढ़ते हैं तो समस्या क्या हो सकती है .. तर्क संकेतक को कुछ काउंटर बैक में वापस ले जाने और फिर पढ़ने के लिए होगा। बेशक हमें थोड़ा और कोड लिखना होगा .. तो इस डिजाइन में क्या गलत हो सकता है? –

+0

अच्छा विचार यह है कि एक सामान्य आधार दृष्टिकोण है जो मूल रूप से (मूल रूप से) सब कुछ के लिए काम करता है। विशेष परिदृश्यों (जैसे पिछड़े पढ़ने या यादृच्छिक पहुंच) में अन्य एक्सेस स्कीम होने से आपको कुछ भी नहीं रोका जा रहा है – Foxfire

+0

बेसिक एसआरपी :)। ऑब्जेक्ट्स में गैर आवश्यक कार्यक्षमता न जोड़ें। इसके अलावा - मुझे बुलेट 4 पसंद है। अगर आपको इसकी ज़रूरत है तो बफरिंग को जोड़ना आसान है। – Goran

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