1. घर
  2. सवाल और जवाब
  3. आप कितना रक्षात्मक होना चाहिए?

आप कितना रक्षात्मक होना चाहिए?

2009-12-16 16 views
6

संभव डुप्लिकेट:
Defensive programmingआप कितना रक्षात्मक होना चाहिए?

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

कुछ लोगों ने महसूस किया कि केवल शून्य सूचक के लिए एक जांच की आवश्यकता थी। मैंने सवाल किया कि क्या इसे उच्च स्तर पर चेक किया जा सकता है, इसके बजाए इसे हर तरीके से पारित किया जा सकता है, और शून्य के लिए जांच बहुत सीमित जांच थी यदि बिंदु के दूसरे छोर पर वस्तु कुछ आवश्यकताओं को पूरा नहीं करती थी।

मैं समझता हूँ और सहमत हैं कि अशक्त के लिए एक जाँच कुछ नहीं से बेहतर है, लेकिन यह मेरे लिए लगता है कि केवल अशक्त के लिए जाँच सुरक्षा की झूठी भावना प्रदान करता है के बाद से यह दायरे में सीमित है। यदि आप यह सुनिश्चित करना चाहते हैं कि सूचक उपयोग योग्य है, तो शून्य से अधिक की जांच करें।

इस विषय पर आपके अनुभव क्या हैं? अधीनस्थ तरीकों से पारित पैरामीटर के लिए आप अपने कोड में सुरक्षा कैसे लिखते हैं?

स्रोत

2009-12-16 TERACytE

+4

http://stackoverflow.com/questions/6847/defensive- प्रोग्रामिंग के कई अन्य लोगों के बीच। –

+0

इस प्रकार का सवाल हमेशा मुझे श्री हेइजेनबर्ग (http://en.wikipedia.org/wiki/Werner_Heisenberg) के बारे में सोचता है। – jldupont

+4

रक्षात्मक प्रोग्रामिंग केवल पर्याप्त लक्षण नहीं है या सही यूनिट परीक्षण नहीं है, एर्लांग जैसे लैंगुग वास्तव में रक्षात्मक प्रोग्रामिंग को हतोत्साहित करते हैं क्योंकि यह बड़ी समस्याओं को मुखौटा करता है, और मैं इससे सहमत हूं। –

उत्तर

15

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

कच्चे पॉइंटर्स का उपयोग करने तक, आम तौर पर आप जो कर सकते हैं सबसे अच्छा यह है कि सूचक शून्य नहीं है। यदि आप जानते हैं कि उस स्मृति में क्या होना चाहिए तो आप यह सुनिश्चित कर सकते हैं कि सामग्री किसी भी तरह से सुसंगत है। यह सवाल पूछता है कि क्यों उस स्मृति को किसी ऑब्जेक्ट में लपेटा नहीं गया है जो इसकी स्थिरता को स्वयं सत्यापित कर सकता है।

तो, आप इस मामले में कच्चे सूचक का उपयोग क्यों कर रहे हैं? क्या संदर्भ या स्मार्ट पॉइंटर का उपयोग करना बेहतर होगा? क्या पॉइंटर में संख्यात्मक डेटा होता है, और यदि ऐसा है, तो क्या यह उस ऑब्जेक्ट में लपेटना बेहतर होगा जो उस सूचक के जीवन चक्र को प्रबंधित करता है?

इन सवालों के जवाब देने से आप अधिक रक्षात्मक होने का तरीका ढूंढने में मदद कर सकते हैं, जिसमें आप रक्षा के लिए आसान डिज़ाइन के साथ समाप्त हो जाएंगे।

स्रोत

2009-12-16 18:36:02 mch

+1

यह मत भूलना कि आपको अपने नियंत्रण के बाहर चीजों के आस-पास बेहद रक्षात्मक होना चाहिए, यानी "क्या मुझे उम्मीद है कि मैं भागूंगा स्मृति की? " या "क्या मैं धागे से बाहर हो जाऊंगा?" इसके अलावा, +1। – wheaties

+0

मैं @wheaties से सहमत हूं, लेकिन मैं यह जोड़ना चाहता हूं कि "आपके नियंत्रण से बाहर" का मतलब क्लाइंट कोड भी हो सकता है यदि आप एपीआई विकसित कर रहे हैं। एपीआई के माध्यम से उजागर किए गए किसी भी चीज़ के पास इसके आस-पास कई रक्षात्मक कोड होना चाहिए (शायद प्रदर्शन के लिए केवल डीबग बिल्ड में ही)। – rmeador

+0

स्मार्ट पॉइंटर्स बहुत अच्छे हैं और सभी ... लेकिन वे शून्य सूचक त्रुटियों को रोकने के लिए कुछ भी नहीं करते हैं। आपके पास शून्य-मूल्यवान कच्चे सूचक के रूप में आसानी से एक शून्य-मूल्यवान स्मार्ट पॉइंटर हो सकता है। वास्तव में, वास्तव में, चूंकि कच्चे सूचक को शून्य के बजाय अनियंत्रित किया जा सकता है। – Alan

3

सभी गंभीर रूप से, यह कितने कीड़े आप आप पर प्रवृत्त बने रहना होगा करना चाहते हैं पर निर्भर करता है।

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

संक्षेप में, अगर आप को लगता है कि हर किसी को बुला अपने कोड अपने जीवन बर्बाद करने के लिए अपना सर्वश्रेष्ठ करने जा रहा है, तो आप शायद सबसे खराब अपराधियों का एक बहुत मिल जाएगा।

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

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

तो अब, आप अपने बचाव की मुद्रा में और अच्छी तरह से इकाई परीक्षण विधि सोच (जो दुर्भाग्य से एक आंतरिक नल पॉइंटर की जांच की कमी है) और उछाल कहते हैं! NullPointerException एक आंतरिक जांच के बिना, आप के साथ काम कर का कोई तरीका नहीं है कि,:

defensiveMethod(thirdPartySearch("Nothing matches me")); 
// You just passed a null to your own code.

स्रोत

2009-12-16 18:12:10

2

> "उत्पादन कोड अपनी नहीं कर क्या अपनी नहीं होना चाहिए सत्यापित करने के लिए कोशिश कर रहा है" यूनिट कोड है का सत्यापन करने से क्या करना चाहिए परीक्षण " कर"।

मैं एक प्रकाशित एपीआई के अपने हिस्से तक, खुद को शून्य के लिए भी जांच नहीं करता।

स्रोत

2009-12-16 18:15:36

1

यह बहुत अधिक निर्भर करता है; प्रश्न में विधि कभी भी आपके समूह के बाहरी कोड द्वारा बुलाया गया है, या यह एक आंतरिक विधि है?

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

बाहरी रूप से दृश्यमान तरीकों के लिए - यदि आपके पास कोई है - तो आपको हमेशा अपने इनपुट को दोबारा जांचना चाहिए। हमेशा।

स्रोत

2009-12-16 18:16:25

0

आंतरिक तरीकों के लिए, हम आमतौर पर इन प्रकार के चेक के लिए जोर देते हैं। इससे यूनिट परीक्षणों में त्रुटियां मिलती हैं (आपके पास अच्छी परीक्षा कवरेज है, है ना?) या कम से कम एकीकरण परीक्षण में जो दावा के साथ चल रहे हैं।

स्रोत

2009-12-16 18:24:04 xcut

0

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

आप नल पॉइंटर चेकों को छोड़ सकते हैं अगर कोड एक निजी इंटरफ़ेस में है कि आप में से पूरा नियंत्रण है और/या आप एक इकाई परीक्षण या कुछ डीबग बिल्ड परीक्षण (जैसे ज़ोर)

स्रोत

2009-12-16 18:36:30 Alon

+0

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

+0

यह कहने के बिना चला जाता है कि समस्या को ढूंढने के लिए कुछ सुधारात्मक कार्रवाई का पालन किया जाना चाहिए, मैं यह इंगित कर रहा था कि एक त्रुटि को खोजने (और सही करने) एक त्रुटि के रूप में रिलीज की तारीख तक पहुंचने के बाद, यह आकाश-रॉकेट हो सकता है जब आप इसे पीछे छोड़ देते हैं। – Alon

4

है चलाकर अशक्त के लिए जाँच यह जांचने का कोई तरीका नहीं है कि कोई सूचक मान्य है या नहीं।

स्रोत

2009-12-16 18:40:12

+0

आपके परिदृश्य के आधार पर, आप "पॉइंटर वैध होने पर जांच सकते हैं" की जांच कर सकते हैं। यदि आपने ऑब्जेक्ट बनाया है, तो आप इसे "ज्ञात अच्छे पॉइंटर्स" की तालिका में पंजीकृत कर सकते हैं। फिर आप जांच कर सकते हैं कि इसका उपयोग करने से पहले पॉइंटर तालिका में है या नहीं। यदि आपने इसे नहीं बनाया है, तो आपका उत्तर सही है। –

13

सबसे अच्छा तरीका है रक्षात्मक होने की कार्यावधि में अशक्त के लिए संकेत की जाँच करने के लिए नहीं है, लेकिन उस वस्तु में पारित किया जा रहा है, तो रिक्त नहीं होना चाहिए

के साथ शुरू अशक्त हो सकता है से बचने के संकेत का उपयोग कर, उपयोग करने के लिए है संदर्भ! या इसे मूल्य से पास करें! या किसी प्रकार के एक स्मार्ट सूचक का उपयोग करें।

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

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

मैं एक और मुख्यधारा की भाषा के बारे में नहीं सोच सकता जो आपको संकलन समय पर सी ++ के रूप में कई त्रुटियों को पकड़ने की अनुमति देता है। उस क्षमता का उपयोग करें।

स्रोत

2009-12-16 18:44:15 jalf

+1

हास्केल/एफिल इस संबंध में काफी अच्छे हैं, यह नहीं जानते कि उन्हें मुख्यधारा माना जा सकता है हालांकि: x –

+1

हाँ, मैंने लिखा है जब मैंने हास्केल को भी सोचा था (हालांकि मुझे एफिल नहीं पता), लेकिन हाँ, मैं वास्तव में इसे मुख्यधारा नहीं माना। (इस अर्थ में कि सी ++ में लिखे गए एप्लिकेशन में आने के लिए यह बहुत आम है, लेकिन मुझे हास्केल में लिखा गया "जंगली में" इस्तेमाल किया जाने वाला एक प्रोग्राम देखने में आश्चर्यचकित होगा। इसमें कोई संदेह नहीं है, वे इसके बारे में कोई संदेह नहीं हैं बस बहुत आम नहीं है। – jalf

+0

@jalf: मैं आपकी पोस्ट से चिंतित हूं। हालांकि, किसी ऐसे व्यक्ति के लिए जो बहुत मूल बातें (मेरे जैसा) से परे सी ++ नहीं जानता है, यह देखना मुश्किल है कि यह कैसे पूरा किया जाएगा। क्या आप कृपया समझा सकते हैं कैसे कंपेलर को एक नल ऑब्जेक्ट पकड़ने में मदद मिलेगी? – conciliator

0

इस प्रश्न जो मैं पता करने के लिए चाहते हैं में यहाँ काम पर कुछ चीजें हैं:

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

    जहां प्रकार है कि एक डिफ़ॉल्ट प्राप्त होने वाले संभवतः अशक्त संकेत का समर्थन 
    template <class Type, class NullTypeDefault> 
struct possibly_null_ptr { 
    possibly_null_ptr() : p(new NullTypeDefault) {} 
    possibly_null_ptr(Type* p_) : p(p_) {} 
    Type * operator->() { return p.get(); } 
    ~possibly_null_ptr() {} 
    private: 
    shared_ptr<Type> p; 
    friend template<class T, class N> Type & operator*(possibly_null_ptr<T,N>&); 
}; 

template <class Type, class NullTypeDefault> 
Type & operator*(possibly_null_ptr<Type,NullTypeDefault> & p) { 
    return *p.p; 
}

    तब मामलों में possibly_null_ptr<> टेम्पलेट का उपयोग ":

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

स्रोत

2009-12-16 19:07:49

+1

संक्षेप में 'बूस्ट :: वैकल्पिक ' है कि पावेल ने प्रश्न की टिप्पणियों में उल्लेख किया था। –

+0

लेकिन 'वैकल्पिक ' सूचक के मुकाबले "बेहतर" काम नहीं करता है क्योंकि आपको अभी भी यह जांचना होगा कि यह सेट है (बस एक सामान्य सूचक की तरह)। मैंने जो प्रस्ताव दिया था वह डिजाइन के "शून्य ऑब्जेक्ट" व्यवहार का हिस्सा बना रहा था और 'संभावित_null_ptr <>' का उपयोग कर रहा था जैसे कि आप एक सामान्य सूचक, केवल डिफ़ॉल्ट "शून्य" विशेषताओं के साथ। –

1

डीबगिंग बिंदु से, यह सबसे महत्वपूर्ण है कि आपका कोड असफल हो। पहले कोड विफल रहता है, विफलता के बिंदु को ढूंढना आसान है।

स्रोत

2009-12-16 19:14:50 Martin

3

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

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

स्रोत

2009-12-16 19:32:36

+0

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

3

मैं थोड़ा चरम हो सकता हूं, लेकिन मुझे रक्षात्मक प्रोग्रामिंग पसंद नहीं है, मुझे लगता है कि यह आलस्य है जिसने सिद्धांत पेश किया है।

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

आम तौर पर, मैं सीधे 'कच्चे' प्रकार का उपयोग नहीं करता हूं। के उदाहरण देकर स्पष्ट करते हैं:

void myFunction(std::string const& foo, std::string const& bar);

foo और bar के संभावित मूल्य क्या हैं? वैसे यह केवल इतना ही सीमित है कि std::string में क्या हो सकता है ... जो बहुत अस्पष्ट है।

दूसरी ओर:

void myFunction(Foo const& foo, Bar const& bar);

ज्यादा बेहतर है!

  • अगर लोगों को गलती से बहस के क्रम को उल्टा, यह संकलक
  • प्रत्येक वर्ग ने पता लगाया है कि जाँच के मूल्य सही है के लिए पूरी तरह जिम्मेदार है, उन burdenned नहीं कर रहे हैं।

मेरे पास मजबूत टाइपिंग का पक्ष लेने की प्रवृत्ति है। अगर मेरे पास एक प्रविष्टि है जो केवल वर्णमाला वर्णों से बनी होनी चाहिए और 12 वर्ण तक होनी चाहिए, तो मैं std::string को एक छोटे से वर्ग को लपेटना चाहूंगा, जिसमें सरल validate विधि असाइनमेंट की जांच करने के लिए आंतरिक रूप से उपयोग की जाती है, और इसके बजाय उस कक्षा को पास करें । इस तरह से मुझे पता है कि यदि मैं एक बार प्रमाणीकरण दिनचर्या का परीक्षण करता हूं, तो मुझे वास्तव में उन सभी पथों के बारे में चिंता करने की ज़रूरत नहीं है, जिनके माध्यम से वह मूल्य मुझे प्राप्त हो सकता है> यह मेरे पहुंचने पर मान्य होगा।

बेशक, यह नहीं है कि कोड का परीक्षण नहीं किया जाना चाहिए। यह सिर्फ इतना है कि मैं मजबूत encapsulation का पक्ष लेता हूं, और इनपुट की मान्यता मेरी राय में ज्ञान encapsulation का हिस्सा है।

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

स्रोत

2009-12-16 20:01:19

0

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

यदि सूचक को उस ऑब्जेक्ट के साथ कुछ करने के लिए फ़ंक्शन में पारित किया गया है, तो इसके बजाय संदर्भ में पास करें।

रक्षात्मक प्रोग्रामिंग के लिए एक तरीका है जो आप कर सकते हैं लगभग हर चीज पर जोर देना है। परियोजना की शुरुआत में यह परेशान है लेकिन बाद में यह इकाई परीक्षण के लिए एक अच्छा सहायक है।

स्रोत

2009-12-16 20:19:19 dlb

0

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

हम उड़ान सॉफ्टवेयर कर रहे हैं और एक मामूली परेशानी से सॉफ़्टवेयर त्रुटि सीमा के प्रभाव विमान/चालक दल के नुकसान के लिए कर रहे हैं। हम सॉफ़्टवेयर के विभिन्न टुकड़ों को उनके संभावित प्रतिकूल प्रभावों के आधार पर वर्गीकृत करते हैं जो कोडिंग मानकों, परीक्षण इत्यादि को प्रभावित करते हैं। आपको मूल्यांकन करना होगा कि आपके सॉफ़्टवेयर का उपयोग कैसे किया जाएगा और त्रुटियों के प्रभाव और सेट करें कि आप किस स्तर की रक्षाशीलता चाहते हैं (और बर्दाश्त कर सकते हैं)। DO-178B standard इस "डिज़ाइन आश्वासन स्तर" को कॉल करता है।

स्रोत

2009-12-16 20:42:45 progrmr

संबंधित मुद्दे
नवीनतम प्रश्न

 संबंधित मुद्दे