समुराई सिद्धांत

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

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




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

यह प्रतीत होता है सरल सिद्धांत अपवाद से निपटने के कई कठिन सवालों के जवाब प्रदान करता है। क्या फ़ंक्शन के तर्कों की जांच करना आवश्यक है और यदि वे गलत हैं तो क्या करें? क्या मुझे इस फ़ंक्शन की हिम्मत में होने वाले अपवादों को निगलने की ज़रूरत है? अगर कुछ गलत हो गया है और फ़ंक्शन अपना काम नहीं कर सकता है तो क्या मुझे अशक्त या खाली सूची वापस करने की आवश्यकता है? (***)

यदि फ़ंक्शन को अमान्य इनपुट पैरामीटर प्राप्त होते हैं या इसे गलत स्थिति में कहा जाता है, तो अपवाद छोड़ दें; यदि कोई आंतरिक कार्य अपना कार्य करते समय अपवाद फेंकता है, तो इसका मतलब है कि आपका कार्य भी अपना कार्य करने में सक्षम नहीं होगा। इस मामले में, या तो अपवाद को फेंक दें या दूसरे अपवाद में लपेटें।

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

अपवाद के मामले में एक अशक्त वस्तु को वापस करना भी एक खतरनाक अभ्यास है, क्योंकि कॉलिंग कोड बस यह निर्धारित नहीं कर सकता है कि एक खाली वस्तु एक वैध मूल्य है या इसे प्राप्त करते समय कोई त्रुटि हुई:

public SomeEntry ReadEntryById( int id)
{
try
{
// SomeEntry
}
catch (Exception)
{
// ! ,
// , id ?
return null ;
}
}

* This source code was highlighted with Source Code Highlighter .

ऐसे समय होते हैं जब कोई फ़ंक्शन अपवाद को पकड़ सकता है और उसे कॉलिंग कोड में नहीं फेंक सकता है; यह उच्चतम स्तर का एक कार्य हो सकता है और कॉलिंग कोड नहीं हो सकता है। अन्य मामलों में, फ़ंक्शन किसी त्रुटि के होने के बाद अपने आप ठीक होने का प्रयास कर सकता है, लेकिन अंततः, यदि यह प्रयास असफल होता है, तो उसके पास समुराई सिद्धांत का पालन करने के अलावा कोई विकल्प नहीं होगा - "अपना काम करो या मरो।"

--------------

(*) किस तरह के रूपकों के बारे में विवरण के लिए, संबंधित नोटों का संदर्भ लें: क्रमशः "तकनीकी ऋण" और "दूसरी प्रणाली का प्रभाव" ।

(**) "समुराई के सिद्धांत" पर अधिकांश लेख केवल समझौते के दूसरे भाग के बारे में बोलते हैं, जो कहते हैं, किसी भी विधि, एक सच्चे समुराई की तरह, या तो अपना काम करना चाहिए या मरना चाहिए। लेकिन कॉलिंग कोड समुराई या उसके सम्राट का प्रमुख नहीं है, जिसे समुराई को निर्विवाद रूप से पालन करना चाहिए। एक समुराई, एक फ़ंक्शन की तरह, उन कार्यों को नहीं करना चाहिए जो काउंटर को उनके "सम्मान के कोड" पर चलाते हैं; फ़ंक्शन और कॉलिंग कोड के बीच संबंध में, यह महत्वपूर्ण है कि दोनों पक्ष अपने समझौतों का पालन करें।

(***) सॉफ्टवेयर विकास में समुराई सिद्धांत क्रांति नहीं है; सिद्धांत लंबे समय से इसका पालन कर रहे हैं, और कुछ अनुबंध डिजाइन की मदद से इसे औपचारिक रूप से करते हैं। यदि आप पूर्वनिर्धारण और पोस्टकंडिशन की अवधारणाओं से परिचित होना चाहते हैं, तो आप लेख "कोड नहीं लिखने के लिए कैसे करें" से शुरू कर सकते हैं या अनुबंध डिजाइन के विषय के लिए समर्पित लेखों की एक श्रृंखला का उल्लेख कर सकते हैं।