मैंने देखा है कि कई इटरेटर या डेटा पाठक केवल DataReader, XmlReader, IEnumerator, किसी भी (आपको विचार मिला) जैसे आगे हैं।ट्रैवर्सल केवल अधिकतर समय क्यों आगे बढ़ता है?
तो बस पूछ रहे हैं कि वे अग्रेषित केवल आमतौर पर जब मैं अपनी कस्टम जरूरतों के लिए डेटा इटरेटर बनाता हूं तो मैं आमतौर पर दोनों तरफ नेविगेशन के लिए समर्थन जोड़ने का प्रयास करता हूं। मैं मानता हूं कि ज्यादातर समय हमें पिछड़े ट्रैवर्सिंग की आवश्यकता नहीं होती है, लेकिन कभी-कभी हमें आवश्यकता होती है और इसलिए हम temp
चर या कुछ आवश्यक होने पर डेटा को पकड़ने के लिए तैयार करते हैं।
तो मेरी प्रश्न हैं:
आगे केवल सबसे डाटा-Iterators क्यों हैं
मैं गलत एक पिछड़े traversable इटरेटर/डेटा पाठक बनाने में हूँ। यदि नहीं, तो फ्रेमवर्क में इसके अंतर्निहित डेटा इटरेटर्स के लिए ऐसा समर्थन क्यों नहीं है।
हम किसी भी गंभीर प्रदर्शन दोष या उसके ऐसी सुविधा सिर्फ नहीं माना एक अच्छे डिजाइन के लिए है।
यह सवाल मुझे शुरू से ही एक बहुत bugged है लेकिन कभी भी कोई संतोषजनक जवाब मिल गया तो मैं यह पूछ रहा हूँ है.मुझे विश्वास है कि कई डेवलपर्स मुझसे सहमत हो सकता है कि पिछड़े traversing कभी कभी उपयोगी हो सकता है है ।
आप उस परिदृश्य में निश्चित रूप से सही हैं लेकिन एक बड़ी फ़ाइल से डेटा पढ़ने के दौरान यदि हम थोड़ा पिछड़ा पढ़ते हैं तो समस्या क्या हो सकती है .. तर्क संकेतक को कुछ काउंटर बैक में वापस ले जाने और फिर पढ़ने के लिए होगा। बेशक हमें थोड़ा और कोड लिखना होगा .. तो इस डिजाइन में क्या गलत हो सकता है? –
अच्छा विचार यह है कि एक सामान्य आधार दृष्टिकोण है जो मूल रूप से (मूल रूप से) सब कुछ के लिए काम करता है। विशेष परिदृश्यों (जैसे पिछड़े पढ़ने या यादृच्छिक पहुंच) में अन्य एक्सेस स्कीम होने से आपको कुछ भी नहीं रोका जा रहा है – Foxfire
बेसिक एसआरपी :)। ऑब्जेक्ट्स में गैर आवश्यक कार्यक्षमता न जोड़ें। इसके अलावा - मुझे बुलेट 4 पसंद है। अगर आपको इसकी ज़रूरत है तो बफरिंग को जोड़ना आसान है। – Goran