पूर्वप्रतिबंध: Difference between revisions

From Vigyanwiki
m (Abhishek moved page शर्त लगाना to पूर्व प्रतिबंध without leaving a redirect)
 
(5 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Short description|Computer programming concept}}
{{Short description|Computer programming concept}}
{{about|the computer programming concept|the legal term|sine qua non|other uses|Preconditioning (disambiguation)}}
[[कंप्यूटर प्रोग्रामिंग|अभिकलित्र क्रमादेशन]] में, एक पूर्व प्रतिबंध एक प्रतिबंध या [[विधेय (गणित)|विधेय]] है जो [[कोड|कूट]] के कुछ खंड के निष्पादन से पहले या [[औपचारिक विनिर्देश]] में किसी संचालन से पहले सदैव सही होना चाहिए।
{{one source|date=September 2010}}
[[कंप्यूटर प्रोग्रामिंग]] में, एक पूर्व शर्त एक शर्त या [[विधेय (गणित)]] है जो [[कोड]] के कुछ खंड के निष्पादन से पहले या [[औपचारिक विनिर्देश]] में किसी ऑपरेशन से पहले हमेशा सही होना चाहिए।


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


अक्सर, कोड के प्रभावित खंड के दस्तावेज़ीकरण में पूर्व शर्त को शामिल किया जाता है। कभी-कभी कोड के भीतर गार्ड (कंप्यूटर विज्ञान) या [[अभिकथन (कंप्यूटिंग)]] का उपयोग करके पूर्व शर्त का परीक्षण किया जाता है, और कुछ भाषाओं में ऐसा करने के लिए विशिष्ट वाक्य रचना होती है।
प्रायः, कूट के प्रभावित खंड के प्रलेखन में पूर्व प्रतिबंध को सम्मिलित किया जाता है। कभी-कभी कूट के भीतर गार्ड या [[अभिकथन (कंप्यूटिंग)|अभिकथन]] का उपयोग करके पूर्व प्रतिबंध का परीक्षण किया जाता है, और कुछ भाषाओं में ऐसा करने के लिए विशिष्ट वाक्य रचना होती है।


उदाहरण के लिए: [[ कारख़ाने का ]] केवल शून्य से अधिक या उसके बराबर पूर्णांकों के लिए परिभाषित किया गया है। तो एक प्रोग्राम जो एक इनपुट नंबर के फैक्टोरियल की गणना करता है, उसकी पूर्व शर्त होगी कि संख्या एक पूर्णांक हो और यह शून्य से अधिक या उसके बराबर हो।
उदाहरण के लिए: [[ कारख़ाने का |क्रमगुणित]] केवल शून्य से अधिक या उसके समान पूर्णांकों के लिए परिभाषित किया गया है। तो एक क्रमादेश जो एक निवेश संख्या के [[ कारख़ाने का |क्रमगुणित]] की गणना करता है, उसकी पूर्व प्रतिबंध कि संख्या एक पूर्णांक हो और यह शून्य से अधिक या उसके समान हो।
 
== वस्तु-उन्मुख प्रोग्रामिंग में ==
[[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] में पूर्व शर्त | ऑब्जेक्ट-ओरिएंटेड सॉफ्टवेयर विकास [[अनुबंध द्वारा डिजाइन]] का एक अनिवार्य हिस्सा है। अनुबंध द्वारा डिज़ाइन में [[पोस्टकंडिशन]] और [[ वर्ग अपरिवर्तनीय ]] के विचार भी शामिल हैं।
 
किसी भी दिनचर्या के लिए पूर्व शर्त वस्तु स्थिति पर किसी भी बाधा को परिभाषित करती है जो सफल निष्पादन के लिए आवश्यक है। प्रोग्राम डेवलपर के दृष्टिकोण से, यह अनुबंध के नियमित कॉल करने वाले के हिस्से का गठन करता है। कॉल करने वाला तब यह सुनिश्चित करने के लिए बाध्य होता है कि रूटीन को कॉल करने से पहले पूर्व शर्त है। कॉल करने वाले के प्रयास के लिए इनाम को रूटीन की पोस्टकंडिशन कहा जाता है।<ref>[[Bertrand Meyer|Meyer, Bertrand]], ''[[Object-Oriented Software Construction]], second edition,'' [[Prentice Hall]], 1997, p. 342.</ref>


== वस्तु-अभिमुखित क्रमादेशन में ==
वस्तु-अभिमुखित सॉफ़्टवेयर विकास में पूर्व प्रतिबंध [[अनुबंध द्वारा डिजाइन|अनुबंध द्वारा अभिकल्पना]] का एक अनिवार्य भाग है। अनुबंध द्वारा अभिकल्पना में [[पोस्टकंडिशन|पश्चातप्रतिबंध]] और[[ वर्ग अपरिवर्तनीय ]]के विचार भी सम्मिलित हैं।


किसी भी सामान्य के लिए पूर्व प्रतिबंध वस्तु स्थिति पर किसी भी बाधा को परिभाषित करती है जो सफल निष्पादन के लिए आवश्यक है। क्रमादेश विकासक के दृष्टिकोण से, यह अनुबंध के नियमित कॉल करने वाले के हिस्से का गठन करता है। कॉल करने वाला तब यह सुनिश्चित करने के लिए बाध्य होता है कि सामान्य को कॉल करने से पहले पूर्व प्रतिबंध है। कॉल करने वाले के प्रयास के लिए पुरस्कार को सामान्य का [[पोस्टकंडिशन|पश्चातप्रतिबंध]] कहा जाता है।<ref>[[Bertrand Meyer|Meyer, Bertrand]], ''[[Object-Oriented Software Construction]], second edition,'' [[Prentice Hall]], 1997, p. 342.</ref>
=== एफिल उदाहरण ===
=== एफिल उदाहरण ===
[[एफिल (प्रोग्रामिंग भाषा)]] में लिखे गए निम्नलिखित उदाहरण में दिनचर्या एक तर्क के रूप में एक पूर्णांक लेती है जो दिन के एक घंटे के लिए मान्य मान होना चाहिए, i। ई।, 0 से 23, समावेशी। पूर्व शर्त कीवर्ड का अनुसरण करती है <code>require</code>. यह निर्दिष्ट करता है कि तर्क शून्य से अधिक या उसके बराबर होना चाहिए और 23 से कम या उसके बराबर होना चाहिए। टैग<code>valid_argument:</code>इस पूर्व शर्त खंड का वर्णन करता है और रनटाइम पूर्व शर्त उल्लंघन के मामले में इसकी पहचान करने में कार्य करता है।
[[एफिल (प्रोग्रामिंग भाषा)|एफिल]] में लिखे गए निम्नलिखित उदाहरण में सामान्य एक तर्क के रूप में एक पूर्णांक लेती है जो दिन के एक घंटे के लिए मान्य मान होना चाहिए, अर्थात्, 0 से 23, समावेशी है। पूर्व प्रतिबंध संकेतशब्द आवश्यकता का अनुसरण करती है। यह निर्दिष्ट करता है कि तर्क शून्य से अधिक या उसके समान होना चाहिए और 23 से कम या उसके समान होना चाहिए। टैग <nowiki>''</nowiki>मान्य तर्क:" इस पूर्व प्रतिबंध खंड का वर्णन करता है और कार्यावधि पूर्व प्रतिबंध उल्लंघनों के प्रकरण में इसे पहचानने के लिए कार्य करता है।


<syntaxhighlight lang="eiffel">
<syntaxhighlight lang="eiffel">
Line 30: Line 26:
         end
         end
</syntaxhighlight>
</syntaxhighlight>
 
=== पूर्व प्रतिबंध और उत्तराधिकारी ===
 
उत्तराधिकारी की उपस्थिति में, उत्तराधिकारी वर्गों (उपवर्गों) द्वारा वंशागत में मिली सामान्य अपनी पूर्व प्रतिबंधों के बल पर ऐसा करती है। इसका मतलब यह है कि वंशागत सामान्य के किसी भी कार्यान्वयन या पुनर्परिभाषा को भी उनके वंशागत अनुबंध का पालन करने के लिए लिखा जाना चाहिए। पूर्व प्रतिबंध को पुनर्निर्धारित सामान्य में संशोधित किया जा सकता है, लेकिन वे केवल कमजोर हो सकते हैं।<ref>Meyer, 1997, pp. 570–573.</ref> अर्थात्, पुनर्परिभाषित सामान्य ग्राहक के दायित्व को कम कर सकती है, लेकिन इसे बढ़ा नहीं सकती है।
=== पूर्व शर्त और वंशानुक्रम ===
वंशानुक्रम की उपस्थिति में, वंशानुक्रम वर्गों (उपवर्गों) द्वारा विरासत में मिली दिनचर्या अपनी पूर्व शर्तों के बल पर ऐसा करती है। इसका मतलब यह है कि इनहेरिटेड रूटीन के किसी भी कार्यान्वयन या पुनर्परिभाषा को भी उनके इनहेरिटेड अनुबंध का पालन करने के लिए लिखा जाना चाहिए। पूर्व शर्त को पुनर्निर्धारित रूटीन में संशोधित किया जा सकता है, लेकिन वे केवल कमजोर हो सकते हैं।<ref>Meyer, 1997, pp. 570–573.</ref> अर्थात्, पुनर्परिभाषित दिनचर्या ग्राहक के दायित्व को कम कर सकती है, लेकिन इसे बढ़ा नहीं सकती है।


== यह भी देखें ==
== यह भी देखें ==
* अनुबंध द्वारा डिजाइन
* [[अनुबंध द्वारा अभिकल्पना]]
*गार्ड (कंप्यूटर विज्ञान)
*[[गार्ड (अभिकलित्र विज्ञान)]]
* पोस्टकंडिशन
* [[पोस्टकंडिशन|पश्चातप्रतिबंध]]
* [[होरे तर्क]]
* [[होरे तर्क]]
*इनवेरिएंट (कंप्यूटर विज्ञान) शर्तों द्वारा बनाए रखा जाता है
*[[प्रतिबंधों द्वारा बनाए गए अपरिवर्तनीय]]
* [[डेटाबेस ट्रिगर]]
* [[डेटाबेस ट्रिगर|डेटाबेस प्रवर्तक]]  


==संदर्भ==
==संदर्भ==
{{reflist}}
{{reflist}}
[[Category: प्रोग्रामिंग का निर्माण]] [[Category: औपचारिक तरीके]] [[Category: कंप्यूटर विज्ञान में तर्क]]


[[Category: Machine Translated Page]]
[[Category:Created On 02/03/2023]]
[[Category:Created On 02/03/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Short description with empty Wikidata description]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:औपचारिक तरीके]]
[[Category:कंप्यूटर विज्ञान में तर्क]]
[[Category:प्रोग्रामिंग का निर्माण]]

Latest revision as of 15:23, 17 October 2023

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

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

प्रायः, कूट के प्रभावित खंड के प्रलेखन में पूर्व प्रतिबंध को सम्मिलित किया जाता है। कभी-कभी कूट के भीतर गार्ड या अभिकथन का उपयोग करके पूर्व प्रतिबंध का परीक्षण किया जाता है, और कुछ भाषाओं में ऐसा करने के लिए विशिष्ट वाक्य रचना होती है।

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

वस्तु-अभिमुखित क्रमादेशन में

वस्तु-अभिमुखित सॉफ़्टवेयर विकास में पूर्व प्रतिबंध अनुबंध द्वारा अभिकल्पना का एक अनिवार्य भाग है। अनुबंध द्वारा अभिकल्पना में पश्चातप्रतिबंध औरवर्ग अपरिवर्तनीय के विचार भी सम्मिलित हैं।

किसी भी सामान्य के लिए पूर्व प्रतिबंध वस्तु स्थिति पर किसी भी बाधा को परिभाषित करती है जो सफल निष्पादन के लिए आवश्यक है। क्रमादेश विकासक के दृष्टिकोण से, यह अनुबंध के नियमित कॉल करने वाले के हिस्से का गठन करता है। कॉल करने वाला तब यह सुनिश्चित करने के लिए बाध्य होता है कि सामान्य को कॉल करने से पहले पूर्व प्रतिबंध है। कॉल करने वाले के प्रयास के लिए पुरस्कार को सामान्य का पश्चातप्रतिबंध कहा जाता है।[1]

एफिल उदाहरण

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

    set_hour (a_hour: INTEGER)
            -- Set `hour' to `a_hour'
        require
            valid_argument: 0 <= a_hour and a_hour <= 23
        do
            hour := a_hour
        ensure
            hour_set: hour = a_hour
        end

पूर्व प्रतिबंध और उत्तराधिकारी

उत्तराधिकारी की उपस्थिति में, उत्तराधिकारी वर्गों (उपवर्गों) द्वारा वंशागत में मिली सामान्य अपनी पूर्व प्रतिबंधों के बल पर ऐसा करती है। इसका मतलब यह है कि वंशागत सामान्य के किसी भी कार्यान्वयन या पुनर्परिभाषा को भी उनके वंशागत अनुबंध का पालन करने के लिए लिखा जाना चाहिए। पूर्व प्रतिबंध को पुनर्निर्धारित सामान्य में संशोधित किया जा सकता है, लेकिन वे केवल कमजोर हो सकते हैं।[2] अर्थात्, पुनर्परिभाषित सामान्य ग्राहक के दायित्व को कम कर सकती है, लेकिन इसे बढ़ा नहीं सकती है।

यह भी देखें

संदर्भ

  1. Meyer, Bertrand, Object-Oriented Software Construction, second edition, Prentice Hall, 1997, p. 342.
  2. Meyer, 1997, pp. 570–573.