सिंगल एंट्री, सिंगल एग्जिट (एसईएसई) की यह धारणा स्पष्ट संसाधन प्रबंधन वाली भाषाओं से आती है , जैसे सी और असेंबली। सी में, इस तरह कोड संसाधनों को लीक करेगा:
void f()
{
resource res = acquire_resource(); // think malloc()
if( f1(res) )
return; // leaks res
f2(res);
release_resource(res); // think free()
}
ऐसी भाषाओं में, आपके पास मूल रूप से तीन विकल्प हैं:
सफाई कोड दोहराएं।
ओह। अतिरेक हमेशा बुरा होता है।
gotoसफाई कोड पर जाने के लिए a का उपयोग करें ।
यह फ़ंक्शन में अंतिम कोड के लिए क्लीनअप कोड की आवश्यकता है। (और यही कारण है कि कुछ का तर्क है कि gotoइसकी जगह है। और यह वास्तव में है - सी में)
एक स्थानीय चर का परिचय और उस के माध्यम से नियंत्रण प्रवाह में हेरफेर।
नुकसान (लगता है कि नियंत्रण प्रवाह वाक्य रचना के माध्यम से चालाकी से किया है break, return, if, while) ज्यादा नियंत्रण प्रवाह चर के राज्य के माध्यम से चालाकी से (क्योंकि वे चर कोई राज्य है जब आप कलन विधि को देखो) से पालन करने के लिए आसान है।
असेंबली में यह और भी अजीब है, क्योंकि जब आप उस फ़ंक्शन को कॉल करते हैं, तो आप किसी फ़ंक्शन में किसी भी पते पर जा सकते हैं, जिसका प्रभावी अर्थ है कि आपके पास किसी भी फ़ंक्शन में लगभग असीमित संख्या में प्रवेश बिंदु हैं। (कभी-कभी यह मददगार होता है। सी ++ में कई-इनहेरिटेंस परिदृश्यों में thisकॉलिंग virtualफ़ंक्शंस के लिए आवश्यक सूचक समायोजन को लागू करने के लिए इस तरह की थैलियां कंपाइलरों के लिए एक सामान्य तकनीक हैं ।)
जब आपको मैन्युअल रूप से संसाधनों का प्रबंधन करना होता है, तो कहीं भी किसी फ़ंक्शन में प्रवेश करने या बाहर निकलने के विकल्पों का शोषण करने से अधिक जटिल कोड होता है, और इस प्रकार बग्स में। इसलिए, विचार का एक विद्यालय दिखाई दिया जिसने क्लीनर कोड और कम बग पाने के लिए SESE को प्रचारित किया।
हालाँकि, जब कोई भाषा अपवादों को शामिल करती है, (लगभग) किसी भी फ़ंक्शन को समय से पहले (लगभग) किसी भी बिंदु से बाहर किया जा सकता है, इसलिए आपको वैसे भी समय से पहले वापसी के लिए प्रावधान करने की आवश्यकता है। (मुझे लगता finallyहै कि मुख्य रूप से इसके लिए जावा में प्रयोग किया जाता है और using(लागू करते समय IDisposable, finallyअन्यथा) C # में; C ++ के बजाय RAII को नियोजित करता है ।) एक बार जब आप ऐसा कर लेते हैं , तो आप एक प्रारंभिक returnबयान के कारण अपने आप को साफ करने में विफल नहीं हो सकते हैं , इसलिए शायद यह क्या है। SESE के पक्ष में सबसे मजबूत तर्क गायब हो गया है।
जो पठनीयता छोड़ देता है। बेशक, आधा दर्जन returnबयानों के साथ 200 एलओसी समारोह बेतरतीब ढंग से छिड़ गया, यह अच्छी प्रोग्रामिंग शैली नहीं है और पठनीय कोड के लिए नहीं है। लेकिन इस तरह के एक फ़ंक्शन को उन समयपूर्व रिटर्न के बिना समझना आसान नहीं होगा।
उन भाषाओं में जहां संसाधन मैन्युअल रूप से प्रबंधित नहीं होने चाहिए या नहीं होने चाहिए, पुराने SESE सम्मेलन के पालन में बहुत कम या कोई मूल्य नहीं है। OTOH, जैसा कि मैंने ऊपर तर्क दिया है, SESE अक्सर कोड को अधिक जटिल बनाता है । यह एक डायनासोर है जो (सी को छोड़कर) आज की अधिकांश भाषाओं में अच्छी तरह से फिट नहीं है। कोड की समझ में मदद करने के बजाय, यह इसमें बाधा डालता है।
जावा प्रोग्रामर इससे क्यों चिपके रहते हैं? मुझे नहीं पता, लेकिन मेरे (बाहर के) पीओवी से, जावा ने सी (जहां वे समझ में आते हैं) से बहुत सारे सम्मेलनों को लिया और उन्हें अपनी ओओ दुनिया में लागू किया (जहां वे बेकार या एकमुश्त खराब हैं), जहां अब यह चिपक जाता है उन्हें, कोई फर्क नहीं पड़ता कि लागत क्या है। (गुंजाइश की शुरुआत में अपने सभी चर को परिभाषित करने के लिए सम्मेलन की तरह।)
तर्कहीन कारणों से प्रोग्रामर सभी प्रकार की अजीब सूचनाओं से चिपके रहते हैं। (डीप नेस्टेड स्ट्रक्चरल स्टेटमेंट्स - "अरकहेड्स" - पास्कल जैसी भाषाओं में, जिसे एक बार सुंदर कोड के रूप में देखा गया था।) इस पर शुद्ध तार्किक तर्क को लागू करना, उनमें से अधिकांश को उनके स्थापित तरीकों से विचलित करने के लिए मनाने में विफल प्रतीत होता है। इस तरह की आदतों को बदलने का सबसे अच्छा तरीका शायद उन्हें यह सिखाना है कि जो सबसे अच्छा है, वह पारंपरिक नहीं है। आप एक प्रोग्रामिंग शिक्षक होने के नाते, यह आपके हाथ में है।:)
