रक्षात्मक प्रोग्रामिंग

मेरे एक पाठक बैरी गिल्स ने हाल ही में मुझे लिखा और एक दिलचस्प सवाल पूछा, जो, मेरी राय में, चर्चा के लायक है:

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

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

कोड को गिरने दें।

रक्षात्मक प्रोग्रामिंग का मूल्य क्या है यदि आप सब करना चाहते हैं तो तुरंत एक अपवाद फेंक दें? क्या यह कोड को गिरने देने के लिए उतना अच्छा समाधान नहीं होगा? आइए कुछ नमूना कोड देखें।

public class ProductDetailsController { private readonly IUserRepository userRepository; private readonly IProductRepository productRepository; private readonly ICurrencyExchange exchange; public ProductDetailsController( IUserRepository userRepository, IProductRepository productRepository, ICurrencyExchange exchange) { this.userRepository = userRepository; this.productRepository = productRepository; this.exchange = exchange; } public ProductDetailsViewModel GetProductDetails(string userId, string productId) { var user = this.userRepository.Get(userId); var targetCurrency = user.PreferredCurrency; var product = this.productRepository.Get(productId); var convertedPrice = this.exchange.Convert(product.UnitPrice, targetCurrency); return new ProductDetailsViewModel { Name = product.Name, Price = convertedPrice.ToString() }; } } 

इस सरल ProductDetailsController वर्ग में, GetProductDetails विधि ProductDetailsViewModel का एक उदाहरण बनाता है, जो उपयोगकर्ता और उत्पाद जानकारी को रिपॉजिटरी के इंजेक्शन के माध्यम से प्राप्त करता है, उत्पाद की कीमत को उपयोगकर्ता की पसंदीदा मुद्रा में परिवर्तित करता है और उत्पाद डेटा को वापस करता है जिसे स्क्रीन पर प्रदर्शित किया जाना चाहिए। इस लेख के लक्ष्य को प्राप्त करने के लिए, आइए केवल null की जाँच की समस्याओं पर ध्यान दें। GetProductDetails विधि में एक असफल स्क्रिप्ट के माध्यम से कितने कॉल जा सकते हैं? कितनी वस्तुएं अशक्त संदर्भ हो सकती हैं?
काफी, जैसा कि यह पता चला है। यहां तक ​​कि अपनी निर्भरता से अलग, कोड का यह छोटा सा टुकड़ा कम से कम छह मामलों में NullReferenceException को फेंक सकता है। कल्पना करें कि आपको अपने उपयोग प्रणाली से त्रुटि रिपोर्ट मिल रही है। स्टैक ट्रेस पॉइंट GetProductDetails विधि और फेंके गए अपवाद के प्रकार NullReferenceException । अशक्त संदर्भ वाली छह संभावित वस्तुओं में से किसमें त्रुटि हुई?
सिस्टम को गिरने देने से, इस प्रश्न का उत्तर देना हमारे लिए मुश्किल होगा। और यह मत भूलो कि यह केवल एक केस स्टडी है। अधिकांश शोषित कोड जो मुझे मिले थे, उनमें 5 या 6 से अधिक लाइनें थीं, इसलिए त्रुटि का कारण पता लगाना जल्द ही एक बाधा में सुई ढूंढने जैसा कुछ बन सकता है।
बस कोड को गिरने देना बहुत उपयोगी नहीं है। जाहिर है, यदि आप बहुत कम विधियाँ लिखते हैं (एक ऐसी प्रथा जो मैं दृढ़ता से सुझाता हूँ), तो जो समस्या पैदा होती है, वह इतनी ज़रूरी नहीं है, लेकिन जितनी देर तक आपके तरीके, कम पेशेवर, मेरी राय में, अभिव्यक्ति "बस कोड को गिरने दो" लगता है।

सुरक्षात्मक बचाव प्रोग्रामिंग?

स्पष्ट द्वारपालों को null जोड़कर, आप अधिक वर्णनात्मक त्रुटि संदेश फेंक सकते हैं:

 public class ProductDetailsController { private readonly IUserRepository userRepository; private readonly IProductRepository productRepository; private readonly ICurrencyExchange exchange; public ProductDetailsController( IUserRepository userRepository, IProductRepository productRepository, ICurrencyExchange exchange) { if (userRepository == null) throw new ArgumentNullException("userRepository"); if (productRepository == null) throw new ArgumentNullException("productRepository"); if (exchange == null) throw new ArgumentNullException("exchange"); this.userRepository = userRepository; this.productRepository = productRepository; this.exchange = exchange; } public ProductDetailsViewModel GetProductDetails( string userId, string productId) { var user = this.userRepository.Get(userId); if (user == null) throw new InvalidOperationException("User was null."); var targetCurrency = user.PreferredCurrency; var product = this.productRepository.Get(productId); if (product == null) throw new InvalidOperationException("Product was null."); var convertedPrice = this.exchange.Convert(product.UnitPrice, targetCurrency); if (convertedPrice == null) throw new InvalidOperationException("Converted price was null."); return new ProductDetailsViewModel { Name = product.Name, Price = convertedPrice.ToString() }; } } 

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

स्थिरता।

क्या समस्या और इसके समाधान को प्रभावित करने वाले कारकों को संतुलित करना संभव है? हां, यह संभव है, लेकिन यह समझने के लिए कि आपको समस्या के मूल कारण को कैसे समझना चाहिए। प्रारंभिक कोड उदाहरण विशेष रूप से जटिल नहीं है, लेकिन फिर भी, ऐसे कई मामले हैं जहां यह कोड विफल रहता है। अशक्त संदर्भों के लिए, कारण भाषा के डिजाइन में एक गलती है , लेकिन सामान्य तौर पर, सवाल यह है कि क्या आप इनपुट डेटा पर भरोसा कर सकते हैं या नहीं। IUserRepository.Get कॉल के माध्यम से मान लौटाएं (अप्रत्यक्ष रूप से) भी इनपुट हैं।
उस वातावरण पर निर्भर करता है जिसमें आपका प्रोग्राम संचालित होता है, आपके पास या तो इनपुट डेटा पर भरोसा करने की क्षमता है, या आपके पास ऐसा कोई अवसर नहीं है। कल्पना कीजिए, एक पल के लिए, जिस स्थिति में आपका सॉफ़्टवेयर "जंगल" में संचालित होता है। आपका सॉफ़्टवेयर पुन: प्रयोज्य पुस्तकालय या ढांचा हो सकता है। इस स्थिति में, आप इनपुट पर बिल्कुल भी भरोसा नहीं कर सकते। यदि ऐसा है, तो आप स्थिरता के सिद्धांत को लागू करना चाहते हैं और आश्वस्त रह सकते हैं कि आप न केवल इनपुट के संबंध में, बल्कि उत्पादन के लिए भी एक रक्षात्मक शैली में काम कर रहे हैं। दूसरे शब्दों में, आप अन्य संदर्भ कोड के लिए अशक्त संदर्भ (या अन्य शैतानी मूल्यों) को पारित नहीं करना चाहते हैं।
पहले दिया गया कोड उदाहरण अपनी निर्भरता के लिए अशक्त संदर्भ दे सकता है, उदाहरण के लिए, अगर userId = null, या (अधिक परिष्कृत रूप से) अगर user.PreferredCurrency = null. इस प्रकार, स्थिरता के सिद्धांत का पालन करते हुए, आपको और भी अधिक रक्षात्मक भाव जोड़ना होगा:

  public class ProductDetailsController { private readonly IUserRepository userRepository; private readonly IProductRepository productRepository; private readonly ICurrencyExchange exchange; public ProductDetailsController( IUserRepository userRepository, IProductRepository productRepository, ICurrencyExchange exchange) { if (userRepository == null) throw new ArgumentNullException("userRepository"); if (productRepository == null) throw new ArgumentNullException("productRepository"); if (exchange == null) throw new ArgumentNullException("exchange"); this.userRepository = userRepository; this.productRepository = productRepository; this.exchange = exchange; } public ProductDetailsViewModel GetProductDetails( string userId, string productId) { if (userId == null) throw new ArgumentNullException("userId"); if (productId == null) throw new ArgumentNullException("productId"); var user = this.userRepository.Get(userId); if (user == null) throw new InvalidOperationException("User was null."); if (user.PreferredCurrency == null) throw new InvalidOperationException("Preferred currency was null."); var targetCurrency = user.PreferredCurrency; var product = this.productRepository.Get(productId); if (product == null) throw new InvalidOperationException("Product was null."); if (product.Name == null) throw new InvalidOperationException("Product name was null."); if (product.UnitPrice == null) throw new InvalidOperationException("Unit price was null."); var convertedPrice = this.exchange.Convert(product.UnitPrice, targetCurrency); if (convertedPrice == null) throw new InvalidOperationException("Converted price was null."); return new ProductDetailsViewModel { Name = product.Name, Price = convertedPrice.ToString() }; } } 

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

संरक्षित क्षेत्र।

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

 public class ProductDetailsController { private readonly IUserRepository userRepository; private readonly IProductRepository productRepository; private readonly ICurrencyExchange exchange; public ProductDetailsController( IUserRepository userRepository, IProductRepository productRepository, ICurrencyExchange exchange) { if (userRepository == null) throw new ArgumentNullException("userRepository"); if (productRepository == null) throw new ArgumentNullException("productRepository"); if (exchange == null) throw new ArgumentNullException("exchange"); this.userRepository = userRepository; this.productRepository = productRepository; this.exchange = exchange; } public ProductDetailsViewModel GetProductDetails( string userId, string productId) { if (userId == null) throw new ArgumentNullException("userId"); if (productId == null) throw new ArgumentNullException("productId"); var user = this.userRepository.Get(userId); if (user.PreferredCurrency == null) throw new InvalidOperationException("Preferred currency was null."); var targetCurrency = user.PreferredCurrency; var product = this.productRepository.Get(productId); if (product.Name == null) throw new InvalidOperationException("Product name was null."); if (product.UnitPrice == null) throw new InvalidOperationException("Unit price was null."); var convertedPrice = this.exchange.Convert(product.UnitPrice, targetCurrency); return new ProductDetailsViewModel { Name = product.Name, Price = convertedPrice.ToString() }; } } 

यह बेहतर है, लेकिन अभी तक अच्छा नहीं है ... लेकिन प्रतीक्षा करें: पढ़ी गई संपत्तियां भी रिटर्न मान हैं, इसलिए हम उन्हें या तो जांच नहीं सकते हैं:

 public class ProductDetailsController { private readonly IUserRepository userRepository; private readonly IProductRepository productRepository; private readonly ICurrencyExchange exchange; public ProductDetailsController( IUserRepository userRepository, IProductRepository productRepository, ICurrencyExchange exchange) { if (userRepository == null) throw new ArgumentNullException("userRepository"); if (productRepository == null) throw new ArgumentNullException("productRepository"); if (exchange == null) throw new ArgumentNullException("exchange"); this.userRepository = userRepository; this.productRepository = productRepository; this.exchange = exchange; } public ProductDetailsViewModel GetProductDetails( string userId, string productId) { if (userId == null) throw new ArgumentNullException("userId"); if (productId == null) throw new ArgumentNullException("productId"); var user = this.userRepository.Get(userId); var targetCurrency = user.PreferredCurrency; var product = this.productRepository.Get(productId); var convertedPrice = this.exchange.Convert(product.UnitPrice, targetCurrency); return new ProductDetailsViewModel { Name = product.Name, Price = convertedPrice.ToString() }; } } 

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

Encapsulation।

यदि null संदर्भ लौटाना एक त्रुटि है, तो User वर्ग, या Product वर्ग, स्थिरता सिद्धांत का पालन कैसे कर सकते हैं? उसी तरह से:

 public class User { private string preferredCurrency; public User() { this.preferredCurrency = "DKK"; } public string PreferredCurrency { get { return this.preferredCurrency; } set { if (value == null) throw new ArgumentNullException("value"); this.preferredCurrency = value; } } } 

ध्यान दें कि User वर्ग अपने आक्रमणकारियों को कैसे बचाता है । PreferredCurrency संपत्ति कभी भी null नहीं हो सकती है। इस सिद्धांत को एक अन्य नाम से भी जाना जाता है: एनकैप्सुलेशन ।

निष्कर्ष।

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