चतुर कर्म

हाल ही में मैंने डिज़ाइन पैटर्न चुना और एक साथ निष्पादन के लिए एक परियोजना का रीमेक बनाने की कोशिश की। इस कॉकटेल से कुछ विचारों का जन्म हुआ जिसे मैं जनता के साथ साझा करना चाहता हूं।

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

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

चलिए इसका पता लगाते हैं।

आमतौर पर, निष्पादन का उपयोग निम्नानुसार किया जाता है:

 class a { public function mytest() { try { code_which_throw_exception(); } catch(myExceptionType1 $e) { myException1Catcher(); } catch(myExceptionType2 $e) { myException1Catcher(); } ... } } 

लेकिन क्यों, मुझे बताओ, क्या हमारे अपवाद एक "मूक", निष्क्रिय वस्तु हैं? चलो उसे थोड़ा और स्वतंत्रता दें! चूंकि यह एक ऑब्जेक्ट है, यह प्रोसेसिंग लॉजिक को अतिक्रमण कर सकता है।

चलिए हमारे अपवादों को catchException() अपवाद catchException() पद्धति जिसमें हम क्रमशः तर्क myException1Catcher() और myException2Catcher() हैं। इस पद्धति के लिए, हम, उदाहरण के लिए, कॉलिंग ऑब्जेक्ट को एक पैरामीटर के रूप में पास कर सकते हैं।

फिर हमारा कोड निम्नलिखित में बदल जाएगा:

 class a { public function mytest() { try { code_witch_throw_exception(); } catch(myException $e) { $e->catchException($this); } } } 

जैसा कि आप देख सकते हैं, कॉलिंग क्लास का कोड थोड़ा कम हो गया है। क्या उसे कोई बेहतर मिला? यह स्थिति पर निर्भर करता है।

जब यह विधि उपयोगी हो सकती है

यदि किसी बिंदु पर सिस्टम में विभिन्न प्रकार के अपवादों की पर्याप्त बड़ी संख्या उत्पन्न की जा सकती है, तो विधि काफी सुविधाजनक हो सकती है।

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

इस विधि के क्या लाभ हैं?

अपवाद को संभालने वाली वस्तु को इसके सटीक प्रकार को जानने की आवश्यकता नहीं है, क्योंकि सभी अपवादों को उसी तरह से नियंत्रित किया जाता है। उचित संचालन के लिए, इंटरफ़ेस स्तर पर संगतता पर्याप्त है।

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

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