अनुबंध और रक्षात्मक प्रोग्रामिंग द्वारा डिजाइन के बीच अंतर

Question

क्या अनुबंध द्वारा डिजाइनिंग (DbC) रक्षात्मक कार्यक्रम करने का एक तरीका हो सकता है?

क्या प्रोग्रामिंग का एक तरीका दूसरे की तुलना में कुछ मामलों में बेहतर है?

Answer 1

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

DbC स्टाइल में लिखा गया एक वास्तविक वर्गाकार रूट रूट अपने अनुबंध में यह बताता है कि आपको नकारात्मक संख्या में पास होने की अनुमति नहीं है और फिर यह मान लें कि यह कभी भी ऋणात्मक संख्या का सामना नहीं कर सकता है। एक वास्तविक वर्गाकार रूट रूटीन को रक्षात्मक रूप से लिखा जाता है कि यह माना जाएगा कि यह एक नकारात्मक संख्या है और उचित सावधानी बरतें।

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

Answer 2

क्या अनुबंध द्वारा डिजाइनिंग (DbC) रक्षात्मक कार्यक्रम करने का एक तरीका हो सकता है?

हाँ।

"रक्षात्मक प्रोग्रामिंग" अक्सर समय बर्बाद करने का एक बहाना है। यह अक्सर उन चीजों की जांच में समय बर्बाद करता है जो साधारण अपवादों का कारण बनेंगे। अपवादों के बजाय, अतिरिक्त IF कथन अपवाद-हैंडलिंग खंडों के बजाय लिखे गए हैं।

अनुबंध को परिभाषित करें और इसके साथ किया जाए।

जब कोई अनुबंध का उल्लंघन करता है, तो कार्यक्रम - सामान्य घटनाओं में - सामान्य अपवादों को तोड़ता और उठाता है जिन्हें सामान्य रूप से नियंत्रित किया जा सकता है।

"रक्षात्मक प्रोग्रामिंग" और "त्रुटि निवारण" त्रुटियों को जोड़ने के लिए दिखाया जा सकता है (क्योंकि त्रुटि निवारण जाँचें स्वयं त्रुटिपूर्ण हैं) त्रुटियों को रोकने के बजाय।

एक्सेप्शन हैंडलिंग "डिफेंसिव प्रोग्रामिंग" की तुलना में कहीं बेहतर तरीके से साइलेंस, लॉग इन और हैंडल कर सकता है।

Comments

बयानों की तुलना में रक्षात्मक प्रोग्रामिंग केवल शोक है। इसमें कोड समीक्षाएं, स्थिर विश्लेषण, सुरक्षा ऑडिट, सुरक्षित कोडिंग दिशानिर्देश और बहुत कुछ शामिल हैं। इसके अलावा, अपवादों और अपवादों को संभालने (केवल कार्यक्रम को दुर्घटनाग्रस्त और जलने देने के विपरीत) को एक रक्षात्मक प्रोग्रामिंग तकनीक माना जाता है।

— थॉमस ओवेन्स

@ThomasOwens: यह "गुड सॉफ्टवेयर डेवलपमेंट" जैसा लगता है। मैंने केवल रक्षात्मक प्रोग्रामिंग का उपयोग बहुत सारे IF स्टेटमेंट (या अभिकथन) लिखने के बहाने के रूप में किया है जो अपवादों को सामान्य रूप से उठाए जाने से पहले विफल हो जाते हैं। मैं वास्तव में अच्छे विचारों की आपकी लंबी सूची को "रक्षात्मक प्रोग्रामिंग" नहीं कहूंगा। मैं आपके अच्छे विचारों की सूची को "प्रोग्रामिंग" कहूंगा। इस तरह हम आपके द्वारा सूचीबद्ध सभी स्मार्ट चीजों से समय-बर्बाद को अलग कर सकते हैं।

— एस.लॉट

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

— थॉमस ओवेन्स

@ThomasOwens: "शायद यह एक व्यापक परिभाषा है"। इस बात से सहमत। यह अच्छे विचारों की एक महान सूची की तरह लगता है।

— S.Lott

-1: मैं नहीं देखता कि डीबीसी रक्षात्मक रूप से प्रोग्राम करने का एक तरीका है, वे मूल रूप से विपरीत हैं। मुझे संदेह है कि सिर्फ समय बर्बाद करने के लिए रक्षात्मक प्रोग्रामिंग करना सामान्य है। और 'त्रुटियों को जोड़ने के लिए दिखाया जा सकता है' को एक उद्धरण की आवश्यकता है क्योंकि यह बिल्कुल स्पष्ट नहीं है।

— मार्क