अपने विशिष्ट प्रश्न का उत्तर देने के लिए: नहीं, भाषा सीखने के दृष्टिकोण से, पुनरावृत्ति एक विशेषता नहीं है। यदि आपके प्रोफेसर ने वास्तव में आपको "सुविधा" का उपयोग करने के लिए चिह्नित किया है, तो वह अभी तक पढ़ाया नहीं गया था, यह गलत था।
लाइनों के बीच पढ़ना, एक संभावना यह है कि पुनरावृत्ति का उपयोग करके, आप कभी भी एक ऐसी सुविधा का उपयोग करने से बचते हैं जो उसके पाठ्यक्रम के लिए एक सीखने का परिणाम माना जाता था। उदाहरण के लिए, हो सकता है आप यात्रा सब पर उपयोग नहीं किया, या हो सकता है आप ही प्रयोग किया जाता forबजाय दोनों का उपयोग कर के छोरों forऔर while। यह सामान्य है कि एक असाइनमेंट का उद्देश्य कुछ चीजों को करने की आपकी क्षमता का परीक्षण करना है, और यदि आप उन्हें करने से बचते हैं, तो आपका प्रोफेसर आपको उस सुविधा के लिए निर्धारित किए गए निशानों को प्रदान नहीं कर सकता है। हालाँकि, यदि वह वास्तव में आपके खोए हुए अंकों का कारण था, तो प्रोफेसर को इसे अपने स्वयं के सीखने के अनुभव के रूप में लेना चाहिए- यदि कुछ सीखने के परिणामों का प्रदर्शन करना एक असाइनमेंट के लिए एक मापदंड है, जिसे छात्रों को स्पष्ट रूप से समझाया जाना चाहिए। ।
यह कहने के बाद, मैं अधिकांश अन्य टिप्पणियों और उत्तरों से सहमत हूं कि पुनरावृत्ति यहाँ पुनरावृत्ति से बेहतर विकल्प है। कुछ कारण हैं, और जबकि अन्य लोगों ने कुछ हद तक उन पर छुआ है, मुझे यकीन नहीं है कि उन्होंने उनके पीछे के विचार को पूरी तरह से समझाया है।
ढेर ओवरफ्लो
अधिक स्पष्ट यह है कि आपको स्टैक ओवरफ्लो त्रुटि होने का जोखिम है। वास्तविक रूप से, आपके द्वारा लिखी गई विधि वास्तव में एक के लिए नेतृत्व करने की बहुत संभावना नहीं है, क्योंकि एक उपयोगकर्ता को वास्तव में स्टैक ओवरफ्लो को ट्रिगर करने के लिए कई बार गलत इनपुट देना होगा।
हालाँकि, एक बात का ध्यान रखें कि केवल विधि ही नहीं, बल्कि कॉल चेन में उच्च या निम्न अन्य विधियाँ स्टैक पर होंगी। इस वजह से, किसी भी विधि को करने के लिए कैसॉली गॉब्लिंग उपलब्ध स्टैक स्पेस एक बहुत अयोग्य चीज है। कोई भी नहीं चाहता है कि जब भी वे कोड को जोखिम के कारण कोड लिखते हैं तो फ्री स्टैक स्पेस के बारे में लगातार चिंता करें।
यह सॉफ्टवेयर डिजाइन में एक अधिक सामान्य सिद्धांत का हिस्सा है जिसे एब्सट्रैक्शन कहा जाता है। अनिवार्य रूप से, जब आप कॉल करते हैं, तो आप DoThing()सभी को यह ध्यान रखना चाहिए कि थिंग किया जाता है। आपको कार्यान्वयन विवरण के बारे में चिंता नहीं करनी चाहिए कि यह कैसे किया जाता है। लेकिन स्टैक का लालची उपयोग इस सिद्धांत को तोड़ देता है, क्योंकि हर बिट कोड को इस बारे में चिंता करनी होती है कि कॉल चेन में कहीं और कितना सुरक्षित रूप से इसे छोड़ दिया गया है।
पठनीयता
दूसरा कारण पठनीयता है। जिस आदर्श को कोड की आकांक्षा करनी चाहिए वह मानव-पठनीय दस्तावेज है, जहां प्रत्येक पंक्ति बस यह बताती है कि वह क्या कर रहा है। इन दो दृष्टिकोणों को लें:
private int getInput() {
int input;
do {
input = promptForInput();
} while (!inputIsValid(input))
return input;
}
बनाम
private int getInput() {
int input = promptForInput();
if(inputIsValid(input)) {
return input;
}
return getInput();
}
हाँ, ये दोनों काम करते हैं, और हाँ वे दोनों समझने में बहुत आसान हैं। लेकिन अंग्रेजी में दो दृष्टिकोणों का वर्णन कैसे किया जा सकता है? मुझे लगता है कि यह कुछ इस तरह होगा:
जब तक इनपुट मान्य नहीं होगा, तब तक मैं इनपुट के लिए संकेत दूंगा और फिर इसे वापस कर दूंगा
बनाम
मैं इनपुट के लिए संकेत दूंगा, फिर यदि इनपुट मान्य है तो मैं उसे वापस कर दूंगा, अन्यथा मुझे इनपुट मिलता है और उसके बदले परिणाम वापस मिलता है
शायद आप उत्तरार्द्ध के लिए थोड़ा कम क्लंकी शब्द के बारे में सोच सकते हैं, लेकिन मुझे लगता है कि आप हमेशा पाएंगे कि पहले वाला अधिक सटीक वर्णन करने वाला है, वैचारिक रूप से, जो आप वास्तव में करने की कोशिश कर रहे हैं। यह कहना नहीं है कि पुनरावृत्ति हमेशा कम पठनीय होती है। ऐसी परिस्थितियों के लिए जहां यह चमकता है, जैसे पेड़ के निशान, आप पुनरावृत्ति और दूसरे दृष्टिकोण के बीच एक ही तरह का पक्ष विश्लेषण कर सकते हैं और आपको लगभग निश्चित रूप से पता चलता है कि पुनरावृत्ति कोड देता है जो कि अधिक स्पष्ट रूप से आत्म-वर्णन करता है, लाइन द्वारा लाइन।
अलगाव में, ये दोनों छोटे बिंदु हैं। यह बहुत संभावना नहीं है कि यह वास्तव में एक स्टैक अतिप्रवाह का कारण होगा, और पठनीयता में लाभ मामूली है। लेकिन कोई भी कार्यक्रम इनमें से कई छोटे निर्णयों का एक संग्रह होने जा रहा है, इसलिए भले ही अलगाव में वे ज्यादा मायने नहीं रखते हैं, लेकिन उन्हें सही पाने के पीछे के सिद्धांतों को सीखना महत्वपूर्ण है।