आड़ की अवधारणा

प्रत्येक प्रोग्रामर एक बार बहुत पहले, अपने पथ की शुरुआत में, कुछ इस तरह से लिखा था:

double div( double a, double b ) { return a / b; } 

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


वास्तव में, हर कदम पर चेक लगाना एक आम बात है। यह एक विश्वविद्यालय में पढ़ाया जाता है, आप अपने दिमाग से भी इस तक पहुँच सकते हैं। लेकिन समय के साथ, विचार आता है कि कुछ गलत है:

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

एक आड़ की अवधारणा इस स्थिति से बाहर निकलने का रास्ता प्रदान करती है।

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

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

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

वस्तुओं का अगला समूह स्वयं "आड़" है। आड़ की भूमिका अंदर सभी को सुरक्षा की गारंटी देना है। कुछ भी नहीं किया जाना चाहिए आड़ में असत्यापित, आंतरिक स्वरूपों में परिवर्तित नहीं, अमान्य, आदि। इसमें विभिन्न प्रकार के कन्वर्टर्स, वैलिडेटर, वेपर और अन्य समान चीजें शामिल हैं।

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

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