गोटो रिटर्न

अब हर कोई समझता है कि गोटो ऑपरेटर का उपयोग करना केवल बुरा नहीं है, बल्कि भयानक अभ्यास है। इसके उपयोग पर बहस XX सदी के 80 के दशक में समाप्त हो गई और इसे अधिकांश आधुनिक प्रोग्रामिंग भाषाओं से बाहर रखा गया। लेकिन, एक वास्तविक बुराई के रूप में, वह खुद को छिपाने और 21 वीं सदी में अपवादों की आड़ में पुनर्जीवित होने में कामयाब रहा।

अपवाद, एक तरफ, आधुनिक प्रोग्रामिंग भाषाओं में एक काफी सरल अवधारणा है। दूसरी ओर, वे अक्सर गलत तरीके से उपयोग किए जाते हैं। एक सरल और प्रसिद्ध नियम है - अपवाद केवल क्षति से निपटने के लिए हैं। और यह "ब्रेकडाउन" की अवधारणा की बहुत ही ढीली व्याख्या है, GOTO का उपयोग करने की सभी समस्याओं की ओर जाता है।

सैद्धांतिक उदाहरण

ब्रेकडाउन और नकारात्मक व्यावसायिक परिदृश्यों के बीच का अंतर स्पष्ट रूप से लॉगिन विंडो पर बहुत सरल उपयोग के मामले में दिखाई देता है:

1. उपयोगकर्ता लॉगिन / पासवर्ड दर्ज करता है।
2. उपयोगकर्ता "लॉगिन" बटन पर क्लिक करता है।
3. क्लाइंट एप्लिकेशन सर्वर को एक अनुरोध भेजता है।
4. सर्वर सफलतापूर्वक उपयोगकर्ता नाम / पासवर्ड की जाँच करता है (सफलता के रूप में संबंधित जोड़ी की उपस्थिति पर विचार करता है)।
5. सर्वर क्लाइंट को जानकारी भेजता है कि प्रमाणीकरण सफल था और संक्रमण पृष्ठ का लिंक।
6. ग्राहक निर्दिष्ट पृष्ठ पर जाता है।

और एक नकारात्मक विस्तार:

4.1। सर्वर को संबंधित लॉगिन / पासवर्ड जोड़ी नहीं मिली और इस बारे में ग्राहक को सूचना भेजता है।

उस परिदृश्य पर विचार करने के लिए 4.1 एक "समस्या" है और इसलिए इसे एक अपवाद का उपयोग करके लागू किया जाना चाहिए यह काफी सामान्य गलती है। वास्तव में ऐसा नहीं है। लॉगिन और पासवर्ड बेमेल हमारे मानक उपयोगकर्ता अनुभव का हिस्सा हैं, जैसा कि स्क्रिप्ट के व्यावसायिक तर्क द्वारा प्रदान किया गया है। हमारे व्यावसायिक ग्राहक इस विकास की अपेक्षा करते हैं। इसलिए, यह ब्रेकडाउन नहीं है और आप यहां अपवादों का उपयोग नहीं कर सकते।

ब्रेकडाउन हैं: क्लाइंट और नॉर्थ के बीच कनेक्शन का डिसकनेक्शन, डीबीएमएस की दुर्गमता, डेटाबेस में गलत स्कीम। और एक लाख और कारण जो हमारे अनुप्रयोगों को तोड़ते हैं और उपयोगकर्ता के व्यावसायिक तर्क से कोई लेना-देना नहीं है।

एक परियोजना में, जिसके विकास में मैंने भाग लिया, एक अधिक जटिल लॉगऑन तर्क था। एक पंक्ति में 3 बार गलत पासवर्ड दर्ज करके, उपयोगकर्ता को 15 मिनट के लिए अस्थायी रूप से अवरुद्ध किया गया था। एक अस्थायी लॉक में एक पंक्ति में 3 बार हो रही है, उपयोगकर्ता को एक स्थायी लॉक प्राप्त हुआ। उपयोगकर्ता के प्रकार के आधार पर अतिरिक्त नियम भी थे। अपवाद कार्यान्वयन ने नए नियमों को लागू करना बेहद कठिन बना दिया है।

इस उदाहरण पर विचार करना दिलचस्प होगा, लेकिन यह बहुत बड़ा है और बहुत दृश्य नहीं है। अपवादों पर व्यावसायिक तर्क के साथ भ्रमित करने वाला कोड कैसे स्पष्ट और संक्षिप्त हो जाता है, मैं आपको एक अन्य उदाहरण में दिखाऊंगा।

उदाहरण लोड हो रहा है गुण

इस कोड को देखने की कोशिश करें और स्पष्ट रूप से समझें कि यह क्या करता है। प्रक्रिया काफी सरल तर्क के साथ बड़ी नहीं है। एक अच्छी प्रोग्रामिंग शैली के साथ, इसके सार की समझ 2-3 मिनट से अधिक नहीं होनी चाहिए (मुझे याद नहीं है कि मुझे इस कोड को पूरी तरह से समझने में कितना समय लगा, लेकिन निश्चित रूप से 15 मिनट से अधिक)।

private WorkspaceProperties(){ Properties loadedProperties = readPropertiesFromFile(WORK_PROPERTIES_PATH, true); //These mappings will replace any mappings that this hashtable had for any of the //keys currently in the specified map. getProperties().putAll( loadedProperties ); //     loadedProperties = readPropertiesFromFile(MY_WORK_PROPERTIES_PATH, false); if (loadedProperties != null){ getProperties().putAll( loadedProperties ); } System.out.println("Loaded properties:" + getProperties()); } /** *  ,    . * @param filepath * @param throwIfNotFound -  FileNotFoundException,     * @return    null,      !throwIfNotFound * @throws FileNotFoundException throwIfNotFound        * @throws IOException     */ private Properties readPropertiesFromFile(String filepath, boolean throwIfNotExists){ Properties loadedProperties = new Properties(); System.out.println("Try loading workspace properties" + filepath); InputStream is = null; InputStreamReader isr = null; try{ int loadingTryLeft = 3; String relativePath = ""; while (loadingTryLeft > 0){ try{ File file = new File(relativePath + filepath); is = new FileInputStream(file); isr = new InputStreamReader( is, "UTF-8"); loadedProperties.load(isr); loadingTryLeft = 0; } catch( FileNotFoundException e) { loadingTryLeft -= 1; if (loadingTryLeft > 0) relativePath += "../"; else throw e; } finally { if (is != null) is.close(); if (isr != null) isr.close(); } } System.out.println("Found file " + filepath); } catch( FileNotFoundException e) { System.out.println("File not found " + filepath); if (throwIfNotExists) throw new RuntimeException("Can`t load workspace properties." + filepath + " not found", e ); }catch (IOException e){ throw new RuntimeException("Can`t read " + filepath, e); } return loadedProperties; } 

तो, चलिए रहस्य को उजागर करते हैं - यहां क्या हो रहा है। दो फ़ाइलों के गुणों को WORK_PROPERTIES - आवश्यक WORK_PROPERTIES और अतिरिक्त MY_WORK_PROPERTIES , सामान्य संपत्ति स्टोर में जोड़ रहे हैं। एक बारीकियों है - हम नहीं जानते कि वास्तव में विशिष्ट गुण फ़ाइल कहाँ स्थित है - यह वर्तमान निर्देशिका और पूर्वजों निर्देशिका (तीन स्तर तक) में दोनों झूठ बोल सकती है।

कम से कम दो चीजें यहां भ्रामक हैं: throwIfNotExists पैरामीटर और बड़े लॉजिक ब्लॉक इन catch FileNotFoundException । यह सभी अपारदर्शी संकेत - अपवाद व्यावसायिक तर्क को लागू करने के लिए उपयोग किए जाते हैं (लेकिन यह कैसे समझा जाए कि एक परिदृश्य में, एक अपवाद को फेंकना एक विफलता है, और दूसरे में नहीं?)।

सही अनुबंध करना

सबसे पहले, throwIfNotExists । अपवादों के साथ काम करते समय, यह समझना बहुत महत्वपूर्ण है कि उपयोग मामलों के संदर्भ में वास्तव में इसे कहाँ संसाधित किया जाना है। इस स्थिति में, यह स्पष्ट है कि readPropertiesFromFile विधि readPropertiesFromFile तय नहीं कर सकती है कि फ़ाइल की अनुपस्थिति "खराब" कब है और यह "अच्छा" कब है। ऐसा निर्णय इसके आह्वान पर किया जाता है। टिप्पणियों से पता चलता है कि हम तय करते हैं कि यह फ़ाइल मौजूद होनी चाहिए या नहीं। लेकिन वास्तव में, हम रुचि रखते हैं कि फाइल ही नहीं, बल्कि उसमें से सेटिंग्स। दुर्भाग्य से, यह कोड से पालन नहीं करता है।

हम इन दोनों कमियों को ठीक करते हैं:

 Properties loadedProperties = readPropertiesFromFile(WORK_PROPERTIES_PATH); if (loadedProperties.isEmpty()) { throw new RuntimeException("Can`t load workspace properties"); } loadedProperties = readPropertiesFromFile(MY_WORK_PROPERTIES_PATH); getProperties().putAll( loadedProperties ); 

अब शब्दार्थ को स्पष्ट रूप से दिखाया गया है -
WORK_PROPERTIES निर्दिष्ट होना चाहिए, लेकिन MY_WORK_PROPERTIES नहीं MY_WORK_PROPERTIES । इसके अलावा रिफैक्टरिंग के दौरान, मैंने देखा कि readPropertiesFromFile कभी भी null नहीं लौट सकती है और MY_WORK_PROPERTIES पढ़ते समय इसका लाभ उठा MY_WORK_PROPERTIES ।

हम बिना टूटे जांच करते हैं

पिछले रिफैक्टरिंग ने भी कार्यान्वयन को प्रभावित किया, लेकिन महत्वपूर्ण रूप से नहीं। मैंने अभी-अभी throwIfNotExists दिया है throwIfNotExists प्रोसेसिंग throwIfNotExists :

 if (throwIfNotExists) throw new RuntimeException(…); 

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

File.canRead() पढ़ने के लिए फ़ाइल की उपलब्धता की जाँच करने के लिए एक फ़ंक्शन है। इसका उपयोग करके, आप catch में व्यापारिक तर्क से छुटकारा पा सकते हैं catch

  try{ File file = new File(relativePath + filepath); is = new FileInputStream(file); isr = new InputStreamReader( is, "UTF-8"); loadedProperties.load(isr); loadingTryLeft = 0; } catch( FileNotFoundException e) { loadingTryLeft -= 1; if (loadingTryLeft > 0) relativePath += "../"; else throw e; } finally { if (is != null) is.close(); if (isr != null) isr.close(); } } 

कोड बदलने पर, हमें निम्नलिखित मिलते हैं:

 private Properties readPropertiesFromFile(String filepath) { Properties loadedProperties = new Properties(); System.out.println("Try loading workspace properties" + filepath); try { int loadingTryLeft = 3; String relativePath = ""; while (loadingTryLeft > 0) { File file = new File(relativePath + filepath); if (file.canRead()) { InputStream is = null; InputStreamReader isr = null; try { is = new FileInputStream(file); isr = new InputStreamReader(is, "UTF-8"); loadedProperties.load(isr); loadingTryLeft = 0; } finally { if (is != null) is.close(); if (isr != null) isr.close(); } } else { loadingTryLeft -= 1; if (loadingTryLeft > 0) { relativePath += "../"; } else { throw new FileNotFoundException(); } } } System.out.println("Found file " + filepath); } catch (FileNotFoundException e) { System.out.println("File not found " + filepath); } catch (IOException e) { throw new RuntimeException("Can`t read " + filepath, e); } return loadedProperties; } 

मैंने चरों के स्तर ( isr , isr ) को न्यूनतम अनुमत कर दिया।

इस तरह के सरल रीफैक्टरिंग से कोड की पठनीयता में काफी सुधार होता है। कोड सीधे एल्गोरिथ्म को प्रदर्शित करता है (यदि फ़ाइल मौजूद है, तो हम इसे पढ़ते हैं, अन्यथा हम प्रयासों की संख्या कम कर देते हैं और ऊपर दी गई निर्देशिका में देखते हैं)।

खुलासा GOTO

अगर फ़ाइल नहीं मिली तो उस स्थिति में विस्तार से विचार करें:

 } else { loadingTryLeft -= 1; if (loadingTryLeft > 0) { relativePath += "../"; } else { throw new FileNotFoundException(); } } 

यह देखा जा सकता है कि यहां निष्पादन चक्र को बाधित करने और वास्तव में गोटो फ़ंक्शन करने के लिए अपवाद का उपयोग किया जाता है।

संदेहियों के लिए, हम एक और बदलाव करेंगे। loadingTryLeft = 0 में एक छोटी बैसाखी का उपयोग करने के बजाय loadingTryLeft = 0 (बैसाखी, क्योंकि वास्तव में एक सफल प्रयास शेष प्रयासों loadingTryLeft = 0 संख्या में loadingTryLeft = 0 नहीं करता है), हम स्पष्ट रूप से संकेत देते हैं कि फ़ाइल को पढ़ने से फ़ंक्शन से बाहर निकल जाता है (संदेश लिखने के लिए भूलकर भी)

 try { is = new FileInputStream(file); isr = new InputStreamReader(is, "UTF-8"); loadedProperties.load(isr); System.out.println("Found file " + filepath); return loadedProperties; } finally { 

यह हमें while (loadingTryLeft > 0) स्थिति को बदलने की अनुमति देता है while (loadingTryLeft > 0) while(true) :

 try { int loadingTryLeft = 3; String relativePath = ""; while (true) { File file = new File(relativePath + filepath); if (file.canRead()) { InputStream is = null; InputStreamReader isr = null; try { is = new FileInputStream(file); isr = new InputStreamReader(is, "UTF-8"); loadedProperties.load(isr); System.out.println("Found file " + filepath); return loadedProperties; } finally { if (is != null) is.close(); if (isr != null) isr.close(); } } else { loadingTryLeft -= 1; if (loadingTryLeft > 0) { relativePath += "../"; } else { throw new FileNotFoundException(); // GOTO: FFN } } } } catch (FileNotFoundException e) { // LABEL: FFN System.out.println("File not found " + filepath); } catch (IOException e) { throw new RuntimeException("Can`t read " + filepath, e); } 

स्पष्ट गलत गंध से छुटकारा पाने के लिए throw new FileNotFoundException , आपको फ़ंक्शन अनुबंध को याद रखना होगा। किसी भी स्थिति में, फ़ंक्शन गुणों का एक सेट लौटाता है, यदि वे फ़ाइल नहीं पढ़ सकते हैं, तो इसे खाली लौटाएं। इसलिए, अपवाद को फेंकने और उसे पकड़ने का कोई कारण नहीं है। सामान्य स्थिति while (loadingTryLeft > 0) पर्याप्त है:

 private Properties readPropertiesFromFile(String filepath) { Properties loadedProperties = new Properties(); System.out.println("Try loading workspace properties" + filepath); try { int loadingTryLeft = 3; String relativePath = ""; while (loadingTryLeft > 0) { File file = new File(relativePath + filepath); if (file.canRead()) { InputStream is = null; InputStreamReader isr = null; try { is = new FileInputStream(file); isr = new InputStreamReader(is, "UTF-8"); loadedProperties.load(isr); System.out.println("Found file " + filepath); return loadedProperties; } finally { if (is != null) is.close(); if (isr != null) isr.close(); } } else { loadingTryLeft -= 1; if (loadingTryLeft > 0) relativePath += "../"; } } System.out.println("file not found"); } catch (IOException e) { throw new RuntimeException("Can`t read " + filepath, e); } return loadedProperties; } 

सिद्धांत रूप में, अपवादों के साथ सही काम के दृष्टिकोण से, सब कुछ यहां है। IOException समस्याओं के मामले में एक RuntimeException को फेंकने की आवश्यकता के बारे में संदेह है, लेकिन हम इसे छोड़ देंगे क्योंकि यह संगतता के लिए है।

ग्लॉस लाओ

कुछ छोटी चीजें बची हैं, जिन्हें हम कोड को और भी अधिक लचीला और समझने योग्य बना सकते हैं:

• ReadPropertiesFromFile विधि नाम इसके कार्यान्वयन को उजागर करता है (वैसे, साथ ही फाइलनॉटफ़ाउंड एक्सपोज़र को फेंकता है)। इसे और अधिक तटस्थ और संक्षिप्त कहने के लिए बेहतर है - loadProperties (...)
• विधि एक साथ खोज और पढ़ती है। मेरे लिए, ये दो अलग-अलग जिम्मेदारियां हैं जिन्हें अलग-अलग तरीकों से विभाजित किया जा सकता है।
• कोड मूल रूप से जावा 6 के तहत लिखा गया था, लेकिन अब जावा 7 में उपयोग किया जाता है। यह क्लोजेबल संसाधनों के उपयोग की अनुमति देता है।
• मैं अनुभव से जानता हूं कि जब किसी फ़ाइल के बारे में जानकारी मिली या नहीं मिली, तो सापेक्ष के बजाय फ़ाइल का पूर्ण पथ का उपयोग करना बेहतर है।
• if (loadingTryLeft > 0) relativePath += "../"; - यदि आप ध्यान से कोड को देखते हैं, तो आप देख सकते हैं - यह चेक अनावश्यक है, क्योंकि यदि खोज सीमा समाप्त हो जाती है, तो नए मूल्य का उपयोग वैसे भी नहीं किया जाएगा। और अगर कोड में कुछ अतिश्योक्ति है, तो यह कचरा है जिसे हटा दिया जाना चाहिए।

स्रोत कोड का अंतिम संस्करण:

 private WorkspaceProperties() { super(new Properties()); if (defaultInstance != null) throw new IllegalStateException(); Properties loadedProperties = readPropertiesFromFile(WORK_PROPERTIES_PATH); if (loadedProperties.isEmpty()) { throw new RuntimeException("Can`t load workspace properties"); } getProperties().putAll(loadedProperties); loadedProperties = readPropertiesFromFile(MY_WORK_PROPERTIES_PATH); getProperties().putAll(loadedProperties); System.out.println("Loaded properties:" + getProperties()); } private Properties readPropertiesFromFile(String filepath) { System.out.println("Try loading workspace properties" + filepath); try { int loadingTryLeft = 3; String relativePath = ""; while (loadingTryLeft > 0) { File file = new File(relativePath + filepath); if (file.canRead()) { return read(file); } else { relativePath += "../"; loadingTryLeft -= 1; } } System.out.println("file not found"); } catch (IOException e) { throw new RuntimeException("Can`t read " + filepath, e); } return new Properties(); } private Properties read(File file) throws IOException { try (InputStream is = new FileInputStream(file); InputStreamReader isr = new InputStreamReader(is, "UTF-8")) { Properties loadedProperties = new Properties(); loadedProperties.load(isr); System.out.println("Found file " + file.getAbsolutePath()); return loadedProperties; } } 

सारांश

पार्स किए गए उदाहरण से स्पष्ट रूप से पता चलता है कि स्रोत कोड की लापरवाह हैंडलिंग क्या होती है। ब्रेकडाउन को संभालने के लिए एक अपवाद का उपयोग करने के बजाय, इसका उपयोग व्यापार तर्क को लागू करने के लिए किया गया था। इसने तुरंत इसके समर्थन की जटिलता को जन्म दिया, जो नई आवश्यकताओं को पूरा करने के लिए इसके आगे के विकास में परिलक्षित हुआ और परिणामस्वरूप, संरचनात्मक प्रोग्रामिंग के सिद्धांतों से प्रस्थान किया गया। एक सरल नियम का उपयोग करना - केवल ब्रेकडाउन के लिए अपवाद - आपको गोटो युग में वापस जाने से बचने में मदद करेगा और अपने कोड को साफ, समझने योग्य और एक्स्टेंसिबल रखेगा।