व्यवहार उपप्रकार: Difference between revisions

Latest revision as of 16:18, 27 April 2023

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में, ब्यावहारिक सबटाइपिंग वह सिद्धांत है जिसके अनुसार सबक्लासेस सुपरक्लास के रेफरेंस के माध्यम से साबंधिक उपयोगकर्ताओं की अपेक्षाों को पूरा करना चाहिए, सिर्फ़ संटैक्टिक सुरक्षा (जैसे "मेथड-नॉट-फाउंड" त्रुटियों की अनुपस्थिति) के संदर्भ में ही नहीं बल्कि व्यवहारिक सहीता के संदर्भ में भी। विशेष रूप से, ऑब्जेक्ट के संभावित टाइप के विनिर्देश का उपयोगकर्ता के माध्यम से सिद्धांत को प्रमाणित करने के लिए प्रूफ होना चाहिए, चाहे वह ऑब्जेक्ट उस टाइप का अधिकारी हो या उससे सबटाइप हो।^[1]

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

यह उदाहरण व्यवहारिक सबटाइपिंग का उल्लंघन करता है क्योंकि टाइप स्टैक टाइप क्यू का व्यवहारिक सबटाइप नहीं है: यह स्पष्ट नहीं है कि टाइप स्टैक के के माध्यम से वर्णित व्यवहार (अर्थात लिफो व्यवहार) टाइप क्यू के वर्णन के अनुरूप है (जो फीफो व्यवहार की आवश्यकता होती है)।

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

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

व्यवहार उपप्रकार सत्यापित करना

एक प्रकार S, प्रकार T का आचरणीय उपप्रकार होता है यदि S के विनिर्देश के अनुसार स्वीकृत प्रत्येक व्यवहार का उपयोग T के विनिर्देश के अनुसार स्वीकार्य होता हो। इसमें विशेष रूप से, T का प्रत्येक विधि M के लिए, S में M का विनिर्देश T में से अधिक मजबूत होता है।

यदि किसी मेथड की पूर्व-शर्त P_sऔर उत्तर-शर्त Q_s दी गई हो तथा एक अन्य मेथड की पूर्व-शर्त P_t और उत्तर-शर्त Q_t दी गई हो (औपचारिक रूप से: (P_s, Q_s ) ⇒ (P_t, Q_t)) तो यदि P_s P_t से कमजोर होता है (अर्थात P_t P_s को समर्थन करता है) और Q_s Q_tसे ज़्यादा मजबूत होता है (अर्थात Q_s Q_t को समर्थित करता है) तो P_s और Q_s की मेथड विशिष्टता बढ़ सकती है। अधिक विशिष्ट मेथड विशेषण तब होते हैं जब उनमें पहले से समर्थित इनपुट के लिए आउटपुट पर अधिक विशिष्ट प्रतिबंध लगाए जाएँ या फिर ज़्यादा इनपुट को समर्थित होने की आवश्यकता हो।

उदाहरण के रूप में, एक तर्क x के एक तत्व के शुद्धार्थ की गणना करने वाली एक विधि के लिए (बहुत कमजोर) निर्देशिका का विचार करें, जो एक पूर्व-शर्त 0 ≤ x और एक पोस्ट-शर्त 0 ≤ परिणाम निर्धारित करती है। यह निर्देशिका यह कहती है कि विधि को x के लिए नकारात्मक मूल्यों का समर्थन करने की आवश्यकता नहीं है, और इसे सुनिश्चित करने की आवश्यकता है कि परिणाम भी नॉन-नेगेटिव हो। इस निर्देशिका को मजबूत करने के दो संभव तरीके हैं, जिसमें पोस्ट-शर्त को बलवान बनाकर स्थिति को परिभाषित किया जाता है कि परिणाम = | x | होता है, अर्थात परिणाम x के शुद्धार्थ के समान होता है, या पूर्व-शर्त को "सत्य" बनाकर कमजोर किया जाता है, अर्थात सभी x के लिए समर्थित होना चाहिए। निःसंदेह, हम इन दोनों को एक साथ मिलाकर भी ला सकते हैं, जिसमें उल्लेख किया जाता है कि परिणाम किसी भी मान के x के लिए x के शुद्धार्थ के समान होना चाहिए।

ध्यान दें, चूंकि, पोस्टकंडीशन (Q_s ⇏ Q_t) को मजबूत किए बिना स्पष्टीकरण ((P_s, Q_s) ⇒ (P_t, Q_t)) को मजबूत किया जा सकता है। ^[2]^[3] एक निश्चित मूल्य की विधि के लिए एक विधान सोचें जो एक पूर्व-शर्त 0 ≤ x और एक पोस्ट-शर्त परिणाम = x को निर्धारित करता है। एक विधान जो एक पूर्व-शर्त "सत्य" और एक पोस्ट-शर्त परिणाम = |x| निर्धारित करता है जो इस विधान को मजबूत करता है, के होने पर भी पोस्ट-शर्त परिणाम परिणाम = x को मजबूत नहीं करता हो (या कमजोर नहीं करता हो)। Ps से पहले और "Q_s या नहीं Ps" को "Q_t या नहीं P_t" से मजबूत होने का आवश्यक शर्त एक विधान के लिए होता है। वास्तव में, "परिणाम = |x| या झूठा" "परिणाम = x या x <0" से मजबूत करता है।

स्थानापन्नता

डेटा एबस्ट्रैक्शन और क्लास हायरार्कीज पर एक प्रभावशाली कीनोट एड्रेस^[4]में, ऊप्सला 1987 प्रोग्रामिंग भाषा अनुसंधान सम्मेलन पर, बारबरा लिस्कोवने निम्नलिखित कहा: "यहाँ चाहिए कुछ ऐसा जैसा निम्नलिखित स्थानांतरण गुण हो: अगर प्रत्येक ऑब्जेक्ट o1 के लिए S के प्रकार के एक ऑब्जेक्ट o2 होता है जिसके लिए T के प्रकार के सभी प्रोग्राम P के लिए, P का व्यवहार बदलाव नहीं करता है जब o1 o2 के लिए उपयोग किया जाता है, तो S T का उप-प्रकार है।" यह विशेषण बाद में लिस्कोव प्रतिस्थापन सिद्धांत (एलएसपी) के रूप में जाना जाता है। दुर्भाग्य से, इसमें कई मुद्दे हैं। पहले, इसकी मूल रूप में, यह बहुत मजबूत है: हम धारक वर्ग के व्यवहार को अधिकांशतः उसके उप-वर्ग के व्यवहार से अलग नहीं चाहते हैं; एक उप-वर्ग वस्तु को एक धारक वर्ग वस्तु के लिए बदलना सामान्यतः कार्यक्रम के व्यवहार को बदलने की इच्छा से किया जाता है, चूंकि, यदि व्यवहारी उप-प्रकार का सम्मान किया जाता है, तो इस प्रकार के बदलाव को कार्यक्रम की वांछनीय गुणवत्ताओं को निरंतर रखने वाले तरीके से किया जाता है। दूसरे, इसमें विनिर्देशों का कोई उल्लेख नहीं है, इसलिए यह गलत रीडिंग के लिए निमंत्रित होता है जहां प्रकार S का अंतर्निर्माण प्रकार T के अंतर्निर्माण से समानता की जाती है। इसके कई कारण हैं, एक कारण है कि यह आम स्थिति का समर्थन नहीं करता है जहां T एक अंतर्जात टाइप है और उसका कोई अमल नहीं होता।^[3] तीसरे और सबसे छिपी कमी ओब्जेक्ट-ओरिएंटेड इम्पेरेटिव प्रोग्रामिंग के सन्दर्भ में है कि किसी विशिष्ट टाइप के ऑब्जेक्ट्स पर समग्र या अस्तित्ववादी रूप से किसी दूसरे ऑब्जेक्ट की जगह लेने का विवरण निर्धारित करना कठिनाई होता है, या एक ऑब्जेक्ट को दूसरे के लिए बदलना। ऊपर दिए गए उदाहरण में, हम एक स्टैक ऑब्जेक्ट को एक बैग ऑब्जेक्ट के रूप में उपयोग कर रहे हैं, हम एक स्टैक ऑब्जेक्ट को बैग ऑब्जेक्ट के लिए बदलने नहीं कर रहे हैं।

2016 में एक साक्षात्कार में, लिस्कोव खुद बताती हैं कि वह जो कुछ उन्होंने अपने कीनोट भाषण में प्रस्तुत किया था, वह एक "गैर-आधिकारिक नियम" था, जिसके बाद जीनेट विंग ने प्रस्ताव किया कि वे "इसका त्रुटिहीन अर्थ क्या हो सकता है उसे तय करने की कोशिश करें", जिससे उनके संयुक्त प्रकाशन^[1]पर बहस की गई थी, और वास्तव में "तकनीकी रूप से, इसे ब्यावहारिक सबटाइपिंग कहा जाता है।"^[5] साक्षात्कार के समय, उन्होंने इस संबंध में स्थानांतरण शब्दावली का उपयोग नहीं किया है।

↑ ^1.0 ^1.1 Liskov, Barbara; Wing, Jeannette (1994-11-01). "उपप्रकार की एक व्यवहारिक धारणा". ACM Transactions on Programming Languages and Systems (in English). 16 (6): 1811–1841. doi:10.1145/197320.197383.
↑ Parkinson, Matthew J. (2005). जावा के लिए स्थानीय तर्क (PDF) (PhD). University of Cambridge.
↑ ^3.0 ^3.1 Leavens, Gary T.; Naumann, David A. (August 2015). "व्यवहार उपप्रकार, विनिर्देश वंशानुक्रम और मॉड्यूलर तर्क". ACM Transactions on Programming Languages and Systems. 37 (4). doi:10.1145/2766446.
↑ Liskov, B. (May 1988). "मुख्य पता - डेटा अमूर्तता और पदानुक्रम". ACM SIGPLAN Notices. 23 (5): 17–34. doi:10.1145/62139.62141.
↑ van Vleck, Tom (April 20, 2016). बारबरा लिस्कोव के साथ साक्षात्कार. ACM. Archived from the original on 2021-12-21.

संदर्भ

Parkinson, Matthew J.; Bierman, Gavin M. (January 2008). "Separation logic, abstraction and inheritance". ACM SIGPLAN Notices. 43 (1): 75–86. doi:10.1145/1328897.1328451.

[liskov1994-1] 1.0 ^1.1 Liskov, Barbara; Wing, Jeannette (1994-11-01). "उपप्रकार की एक व्यवहारिक धारणा". ACM Transactions on Programming Languages and Systems (in English). 16 (6): 1811–1841. doi:10.1145/197320.197383.

[2] Parkinson, Matthew J. (2005). जावा के लिए स्थानीय तर्क (PDF) (PhD). University of Cambridge.

[leavens2015-3] 3.0 ^3.1 Leavens, Gary T.; Naumann, David A. (August 2015). "व्यवहार उपप्रकार, विनिर्देश वंशानुक्रम और मॉड्यूलर तर्क". ACM Transactions on Programming Languages and Systems. 37 (4). doi:10.1145/2766446.

[4] Liskov, B. (May 1988). "मुख्य पता - डेटा अमूर्तता और पदानुक्रम". ACM SIGPLAN Notices. 23 (5): 17–34. doi:10.1145/62139.62141.

[5] van Vleck, Tom (April 20, 2016). बारबरा लिस्कोव के साथ साक्षात्कार. ACM. Archived from the original on 2021-12-21.

[1]

[2]

[3]

[4]

[5]

@@ Line 1: / Line 1: @@
-[[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] में, व्यवहार उपप्रकार सिद्धांत है कि उपवर्गों को सुपरक्लास प्रकार के संदर्भों के माध्यम से उपवर्ग वस्तुओं तक पहुंचने वाले ग्राहकों की अपेक्षाओं को पूरा करना चाहिए, न एकमात्र सिंटैक्टिक सुरक्षा के संबंध में (जैसे कि विधि-नहीं-त्रुटियों की अनुपस्थिति) किन्तु यह भी व्यवहार शुद्धता के संबंध में। विशेष रूप से, गुण जो ग्राहक किसी वस्तु के प्रकल्पित प्रकार के विनिर्देश का उपयोग करके सिद्ध कर सकते हैं, भले ही वस्तु वास्तव में उस प्रकार के उपप्रकार का सदस्य हो।
+[[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग |ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]] में, ब्यावहारिक सबटाइपिंग वह सिद्धांत है जिसके अनुसार सबक्लासेस सुपरक्लास के रेफरेंस के माध्यम से साबंधिक उपयोगकर्ताओं की अपेक्षाों को पूरा करना चाहिए, सिर्फ़ संटैक्टिक सुरक्षा (जैसे "मेथड-नॉट-फाउंड" त्रुटियों की अनुपस्थिति) के संदर्भ में ही नहीं बल्कि व्यवहारिक सहीता के संदर्भ में भी। विशेष रूप से, ऑब्जेक्ट के संभावित टाइप के विनिर्देश का उपयोगकर्ता  के माध्यम से सिद्धांत को प्रमाणित करने के लिए प्रूफ होना चाहिए, चाहे वह ऑब्जेक्ट उस टाइप का अधिकारी हो या उससे सबटाइप हो।<ref name="liskov1994">{{Cite journal|last=Liskov|first=Barbara|last2=Wing|first2=Jeannette|date=1994-11-01|title=उपप्रकार की एक व्यवहारिक धारणा|journal=ACM Transactions on Programming Languages and Systems |language=EN|volume=16|issue=6|pages=1811–1841|doi=10.1145/197320.197383}}</ref>
-<ref name="liskov1994">{{Cite journal|last=Liskov|first=Barbara|last2=Wing|first2=Jeannette|date=1994-11-01|title=उपप्रकार की एक व्यवहारिक धारणा|journal=ACM Transactions on Programming Languages and Systems |language=EN|volume=16|issue=6|pages=1811–1841|doi=10.1145/197320.197383}}</ref>उदाहरण के लिए, एक प्रकार की स्टैक और एक प्रकार की कतार पर विचार करें, जिसमें एक तत्व को जोड़ने के लिए एक पुट विधि और एक को हटाने के लिए एक विधि प्राप्त करें। मान लीजिए कि इन प्रकारों से जुड़े दस्तावेज़ीकरण निर्दिष्ट करते हैं कि प्रकार स्टैक के तरीके ढेर के लिए अपेक्षित व्यवहार करेंगे (अर्थात वे स्टैक (सार डेटा प्रकार) व्यवहार प्रदर्शित करेंगे), और उस प्रकार की कतार के तरीके कतारों के लिए अपेक्षित व्यवहार करेंगे (अर्थात वे फीफो प्रदर्शित करेंगे [[फीफो (कंप्यूटिंग और इलेक्ट्रॉनिक्स)]]) व्यवहार)। मान लीजिए, अब, उस प्रकार के ढेर को कतार के उप-वर्ग के रूप में घोषित किया गया था। अधिकांश प्रोग्रामिंग लैंग्वेज कंपाइलर्स दस्तावेज़ीकरण को अनदेखा करते हैं और एकमात्र वे चेक करते हैं जो टाइप सुरक्षा को बनाए रखने के लिए आवश्यक हैं। चूंकि, प्रत्येक प्रकार की कतार के लिए, प्रकार स्टैक मिलान नाम और हस्ताक्षर के साथ एक विधि प्रदान करता है, यह जांच सफल होगी। चूंकि, कतार के दस्तावेज़ीकरण के आधार पर कतार प्रकार के संदर्भ के माध्यम से एक स्टैक ऑब्जेक्ट तक पहुँचने वाले क्लाइंट, फीफो व्यवहार की अपेक्षा करते हैं, किन्तु लिफो व्यवहार का निरीक्षण करते हैं, इन ग्राहकों के शुद्धता प्रमाणों को अमान्य करते हैं और संभावित रूप से पूरे कार्यक्रम के गलत व्यवहार की ओर अग्रसर होते हैं।
+उदाहरण के लिए, एक प्रकार का स्टैक और एक प्रकार का क्यू होते हैं, जिनमें दोनों में पट विधि एक तत्व जोड़ने और एक तत्व हटाने के लिए होती है। मान लीजिए, इन प्रकारों के साथ जुड़े दस्तावेज़ का उल्लेख करता है कि प्रकार स्टैक के विधियों का व्यवहार स्टैक के लिए अपेक्षा के अनुसार होना चाहिए (अर्थात, वे फीफो  व्यवहार प्रदर्शित करेंगे), और कि प्रकार क्यू के विधियों का व्यवहार क्यू के लिए अपेक्षा के अनुसार होना चाहिए (अर्थात, वे [[फीफो (कंप्यूटिंग और इलेक्ट्रॉनिक्स)]]) व्यवहार प्रदर्शित करेंगे)। अब मान लीजिए, कि प्रकार स्टैक को प्रकार क्यू के एक उपप्रकार के रूप में घोषित किया गया था।अधिकांश प्रोग्रामिंग भाषा कंपाइलर दस्तावेज़ीकरण को अनदेखा करते हैं और एकमात्र उन जांचों को निभाते हैं जो प्रकार सुरक्षा को संरक्षित रखने के लिए आवश्यक होते हैं। चूँकि प्रत्येक तरीके के लिए क्यू के मेथड के लिए, स्टैक के पास एक मेल खाता है जिसका नाम और सिग्नेचर मैचिंग होता है, इसलिए यह जाँच सफल होगी। चूंकि, क्यू के प्रलेखन के आधार पर, क्यू के माध्यम से स्टैक ऑब्जेक्ट तक पहुँचने वाले क्लाइंट्स को फीफो व्यवहार की अपेक्षा होगी किन्तु वे लिफो व्यवहार देखेंगे, जिससे इन क्लाइंट्स की सहीता के प्रमाण नकारात्मक हो जाएंगे और कुल प्रोग्राम का गलत व्यवहार हो सकता है।
-यह उदाहरण व्यवहार उपप्रकार का उल्लंघन करता है क्योंकि प्रकार स्टैक क्यू प्रकार का व्यवहार उप प्रकार नहीं है: ऐसा नहीं है कि प्रकार स्टैक (अर्थात लिफो व्यवहार) के दस्तावेज़ीकरण  के माध्यम से वर्णित व्यवहार कतार प्रकार के दस्तावेज़ीकरण के साथ अनुपालन करता है (जिसे फीफो व्यवहार की आवश्यकता होती है) .
+यह उदाहरण व्यवहारिक सबटाइपिंग का उल्लंघन करता है क्योंकि टाइप स्टैक टाइप क्यू का व्यवहारिक सबटाइप नहीं है: यह स्पष्ट नहीं है कि टाइप स्टैक के  के माध्यम से वर्णित व्यवहार (अर्थात लिफो व्यवहार) टाइप क्यू के वर्णन के अनुरूप है (जो फीफो व्यवहार की आवश्यकता होती है)।
-इसके विपरीत, एक प्रोग्राम जहां स्टैक और कतार दोनों एक प्रकार के बैग के उपवर्ग हैं, जिसका विनिर्देश एकमात्र यह है कि यह कुछ तत्व को हटा देता है, व्यवहार उपप्रकार को संतुष्ट करता है और ग्राहकों को उनके माध्यम से अनुमानित प्रकार की वस्तुओं के आधार पर शुद्धता के बारे में सुरक्षित रूप से तर्क करने की अनुमति देता है। के साथ बातचीत। वास्तव में, कोई भी वस्तु जो स्टैक या कतार विनिर्देश को संतुष्ट करती है, वह बैग विनिर्देश को भी संतुष्ट करती है।
+इसके विपरीत, एक कार्यक्रम जहां स्टैक और क्यू बैग नाम के एक टाइप के उपकक्ष होते हैं, जिसके लिए गेट  का विनिर्देश एकमात्र यह है कि यह कुछ तत्व हटाता है, वास्तव में व्यवहारिक उपप्रकार को पूरा करता है और ग्राहकों को आसानी से सहीता के बारे में विचार करने की अनुमति देता है, जिसमें वे उन वस्तुओं के प्रतिक्रिया करते हैं जिनके साथ वे संवाद करते हैं। वास्तव में, स्टैक या क्यू विनिर्देश को पूरा करने वाले कोई भी वस्तु बैग विनिर्देश को भी पूरा करती है।
-इस बात पर जोर देना महत्वपूर्ण है कि क्या टाइप एस, टाइप टी का व्यवहारिक उपप्रकार है, यह एकमात्र टाइप टी के विनिर्देशन (अर्थात प्रलेखन) पर निर्भर करता है; [[प्रकार की सुरक्षा]] का कार्यान्वयन, यदि इसका कोई है, तो इस प्रश्न के लिए पूरी प्रकार से अप्रासंगिक है। दरअसल, टाइप टी को कार्यान्वयन की भी आवश्यकता नहीं है; यह विशुद्ध रूप से अमूर्त वर्ग हो सकता है। बिंदु में एक अन्य स्थितियों के रूप में, उपरोक्त प्रकार का स्टैक प्रकार बैग का एक व्यवहारिक उप प्रकार है, के होने पर भी प्रकार बैग का कार्यान्वयन फीफो व्यवहार प्रदर्शित करता है: क्या मायने रखता है कि प्रकार बैग का विनिर्देश निर्दिष्ट नहीं करता है कि विधि प्राप्त करने से कौन सा तत्व हटा दिया जाता है। इसका अर्थ यह भी है कि व्यवहारिक उपप्रकार की चर्चा एकमात्र सम्मलित प्रत्येक प्रकार के लिए एक विशेष (व्यवहारिक) विनिर्देश के संबंध में की जा सकती है और यदि सम्मलित प्रकार में कोई अच्छी प्रकार से परिभाषित व्यवहार विनिर्देश नहीं है, तो व्यवहारिक उपप्रकार पर सार्थक चर्चा नहीं की जा सकती है।
+महत्वपूर्ण यह है कि टाइप टी के विनिर्देशन (अर्थात प्रलेखन) पर निर्भर करता है कि क्या टाइप एस, टाइप टी का व्यवहारिक उपप्रकार है; इसका कोई अप्रभाव नहीं पड़ता कि टाइप [[प्रकार की सुरक्षा|प्रकार]] टी का कार्यान्वयन होता है या नहीं। वास्तव में, टाइप टी को कार्यान्वयन करने की भी आवश्यकता नहीं है; यह एक पूर्णतः अमूर्त वर्ग हो सकता है। एक और स्थितियों के रूप में, टाइप बैग का विनिर्देश निर्दिष्ट नहीं करता है कि मेथड गेट  के माध्यम से कौन सा तत्व हटाया जाना चाहिए, तो यहां उपस्थित स्टैक टाइप बैग का एक व्यवहारिक उपप्रकार होने के अतिरिक्त, टाइप स्टैक बैग का एक व्यवहारिक उपप्रकार है। इसका अर्थ है कि व्यवहारिक उपप्रकार की चर्चा एक विशेष (व्यवहारिक) विनिर्देश के संबंध में ही की जा सकती है और यदि सम्मिलित प्रकार में कोई अच्छी प्रकार से परिभाषित व्यवहार विनिर्देश नहीं है तो व्यवहारिक उपप्रकार की चर्चा सार्थक नहीं हो सकती है।
 == व्यवहार उपप्रकार सत्यापित करना ==
-एक प्रकार एस एक प्रकार का व्यवहार उपप्रकार है यदि एस के विनिर्देश  के माध्यम से अनुमत प्रत्येक व्यवहार को टी के विनिर्देश  के माध्यम से भी अनुमति दी जाती है। विशेष रूप से, यह आवश्यक है कि टी के प्रत्येक विधि एम के लिए, एस में एम का विनिर्देश है टी में एक से ज्यादा मजबूत।
+एक प्रकार S, प्रकार T का आचरणीय उपप्रकार होता है यदि S के विनिर्देश के अनुसार स्वीकृत प्रत्येक व्यवहार का उपयोग T के विनिर्देश के अनुसार स्वीकार्य होता हो। इसमें विशेष रूप से, T का प्रत्येक विधि M के लिए, S में M का विनिर्देश T में से अधिक मजबूत होता है।
-एक पूर्व शर्त पी  के माध्यम से दिया गया एक विधि विनिर्देश<sub>s</sub> और एक पश्च शर्त क्यू<sub>s</sub> एक पूर्व शर्त पी  के माध्यम से दिए गए एक से अधिक मजबूत है<sub>t</sub> और एक पश्च शर्त क्यू<sub>t</sub> (औपचारिक रूप से: (पी<sub>s</sub>, क्यू<sub>s</sub>) ⇒ (पी<sub>t</sub>, क्यू<sub>t</sub>)) यदि पी<sub>s</sub> पी से कमजोर है<sub>t</sub> (अर्थात पी<sub>t</sub> अर्थ पी<sub>s</sub>) और क्यू<sub>s</sub> क्यू से अधिक शक्तिशाली है<sub>t</sub> (अर्थात क्यू<sub>s</sub> क्यू का तात्पर्य है<sub>t</sub>). यही है, एक विधि विनिर्देश को मजबूत करना पोस्टकंडिशन को मजबूत करके और पूर्व शर्त को कमजोर करके किया जा सकता है। दरअसल, एक विधि विनिर्देश मजबूत होता है यदि यह पहले से समर्थित इनपुट के आउटपुट पर अधिक विशिष्ट बाधाओं को लागू करता है, या यदि इसे अधिक इनपुट की आवश्यकता होती है।
+यदि किसी मेथड की पूर्व-शर्त P<sub>s</sub>और उत्तर-शर्त Q<sub>s</sub> दी गई हो तथा एक अन्य मेथड की पूर्व-शर्त P<sub>t</sub> और उत्तर-शर्त Q<sub>t</sub> दी गई हो (औपचारिक रूप से: (P<sub>s</sub>, Q<sub>s</sub> ) ⇒ (P<sub>t</sub>, Q<sub>t</sub>)) तो यदि P<sub>s</sub> P<sub>t</sub> से कमजोर होता है (अर्थात P<sub>t</sub> P<sub>s</sub> को समर्थन करता है) और Q<sub>s</sub> Q<sub>t</sub>से ज़्यादा मजबूत होता है (अर्थात Q<sub>s</sub> Q<sub>t</sub> को समर्थित करता है) तो P<sub>s</sub> और Q<sub>s</sub> की मेथड विशिष्टता बढ़ सकती है। अधिक विशिष्ट मेथड विशेषण तब होते हैं जब उनमें पहले से समर्थित इनपुट के लिए आउटपुट पर अधिक विशिष्ट प्रतिबंध लगाए जाएँ या फिर ज़्यादा इनपुट को समर्थित होने की आवश्यकता हो।
-उदाहरण के लिए, एक विधि के लिए (बहुत कमजोर) विनिर्देश पर विचार करें , जो एक तर्क x के निरपेक्ष मान की गणना करता है, जो एक पूर्व शर्त 0 ≤ x और एक पश्च शर्त 0 ≤ परिणाम निर्दिष्ट करता है। यह विनिर्देश कहता है कि विधि को x के लिए ऋणात्मक मानों का समर्थन करने की आवश्यकता नहीं है, और इसे एकमात्र यह सुनिश्चित करने की आवश्यकता है कि परिणाम गैर-नकारात्मक भी हो। इस विनिर्देशन को मजबूत करने के दो संभावित तरीके हैं, पोस्ट कंडीशन को राज्य के परिणाम = |x| को मजबूत करके, अर्थात परिणाम x के पूर्ण मान के समान है, या पूर्व शर्त को सही करने के लिए कमजोर करके, अर्थात x के लिए सभी मान समर्थित होने चाहिए। बेशक, हम दोनों को एक विनिर्देश में भी जोड़ सकते हैं जो बताता है कि परिणाम x के किसी भी मान के लिए x के निरपेक्ष मान के समान होना चाहिए।
+उदाहरण के रूप में, एक तर्क x के एक तत्व के शुद्धार्थ की गणना करने वाली एक विधि के लिए (बहुत कमजोर) निर्देशिका का विचार करें, जो एक पूर्व-शर्त 0 ≤ x और एक पोस्ट-शर्त 0 ≤ परिणाम निर्धारित करती है। यह निर्देशिका यह कहती है कि विधि को x के लिए नकारात्मक मूल्यों का समर्थन करने की आवश्यकता नहीं है, और इसे सुनिश्चित करने की आवश्यकता है कि परिणाम भी नॉन-नेगेटिव हो। इस निर्देशिका को मजबूत करने के दो संभव तरीके हैं, जिसमें पोस्ट-शर्त को बलवान बनाकर स्थिति को परिभाषित किया जाता है कि परिणाम = | x | होता है, अर्थात परिणाम x के शुद्धार्थ के समान होता है, या पूर्व-शर्त को "सत्य" बनाकर कमजोर किया जाता है, अर्थात सभी x के लिए समर्थित होना चाहिए। निःसंदेह, हम इन दोनों को एक साथ मिलाकर भी ला सकते हैं, जिसमें उल्लेख किया जाता है कि परिणाम किसी भी मान के x के लिए x के शुद्धार्थ के समान होना चाहिए।
-ध्यान दें, चूंकि, एक विनिर्देश को मजबूत करना संभव है ((पी<sub>s</sub>, क्यू<sub>s</sub>) ⇒ (पी<sub>t</sub>, क्यू<sub>t</sub>)) पश्च शर्त को मजबूत किए बिना (क्यू<sub>s</sub> ⇏ क्यू<sub>t</sub>).<ref>{{cite thesis |type=PhD |last=Parkinson |first=Matthew J. |date=2005 |title=जावा के लिए स्थानीय तर्क|publisher=University of Cambridge |url=https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-654.pdf}}</ref><ref name="leavens2015">{{cite journal |last=Leavens |first=Gary T. |last2=Naumann |first2=David A. |date=August 2015 |title= व्यवहार उपप्रकार, विनिर्देश वंशानुक्रम और मॉड्यूलर तर्क|journal=ACM Transactions on Programming Languages and Systems |volume=37 |issue=4 |doi=10.1145/2766446|url=https://lib.dr.iastate.edu/cgi/viewcontent.cgi?article=1249&context=cs_techreports }}</ref> निरपेक्ष मान विधि के लिए एक विनिर्देश पर विचार करें जो एक पूर्व शर्त 0 ≤ x और एक पोस्टकंडिशन परिणाम = x निर्दिष्ट करता है। विनिर्देश जो एक पूर्व शर्त सत्य और एक पश्च शर्त परिणाम = |x| निर्दिष्ट करता है इस विनिर्देशन को मजबूत करता है, के होने पर भी पोस्टकंडिशन परिणाम = |x| स्थिति के बाद के परिणाम = x को मजबूत (या कमजोर) नहीं करता है। पूर्व शर्त पी के साथ एक विनिर्देश के लिए आवश्यक शर्त<sub>s</sub> और पश्च शर्त क्यू<sub>s</sub> पूर्व शर्त पी के साथ एक विनिर्देश से अधिक मजबूत होना<sub>t</sub> और पश्च शर्त क्यू<sub>t</sub> क्या वह पी<sub>s</sub> पी से कमजोर है<sub>t</sub> और क्यू<sub>s</sub> या नहीं पी<sub>s</sub>क्यू से अधिक शक्तिशाली है<sub>t</sub> या नहीं पी<sub>t</sub>. दरअसल, परिणाम = |x| या गलत परिणाम = x या x < 0 को मजबूत करता है।
+ध्यान दें, चूंकि, पोस्टकंडीशन (Q<sub>s</sub> ⇏ Q<sub>t</sub>) को मजबूत किए बिना स्पष्टीकरण ((P<sub>s</sub>, Q<sub>s</sub>) ⇒ (P<sub>t</sub>, Q<sub>t</sub>)) को मजबूत किया जा सकता है। <ref>{{cite thesis |type=PhD |last=Parkinson |first=Matthew J. |date=2005 |title=जावा के लिए स्थानीय तर्क|publisher=University of Cambridge |url=https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-654.pdf}}</ref><ref name="leavens2015">{{cite journal |last=Leavens |first=Gary T. |last2=Naumann |first2=David A. |date=August 2015 |title= व्यवहार उपप्रकार, विनिर्देश वंशानुक्रम और मॉड्यूलर तर्क|journal=ACM Transactions on Programming Languages and Systems |volume=37 |issue=4 |doi=10.1145/2766446|url=https://lib.dr.iastate.edu/cgi/viewcontent.cgi?article=1249&context=cs_techreports }}</ref> एक निश्चित मूल्य की विधि के लिए एक विधान सोचें जो एक पूर्व-शर्त 0 ≤ x और एक पोस्ट-शर्त परिणाम = x को निर्धारित करता है। एक विधान जो एक पूर्व-शर्त "सत्य" और एक पोस्ट-शर्त परिणाम = |x| निर्धारित करता है जो इस विधान को मजबूत करता है, के होने पर भी पोस्ट-शर्त परिणाम परिणाम = x को मजबूत नहीं करता हो (या कमजोर नहीं करता हो)। Ps से पहले और "Q<sub>s</sub> या नहीं Ps" को "Q<sub>t</sub> या नहीं P<sub>t</sub>" से मजबूत होने का आवश्यक शर्त एक विधान के लिए होता है। वास्तव में, "परिणाम = |x| या झूठा" "परिणाम = x या x <0" से मजबूत करता है।
 == स्थानापन्नता ==
-एक प्रभावशाली मुख्य भाषण में<ref>{{Cite journal| last1 = Liskov | first1 = B. | authorlink1 = Barbara Liskov| title = मुख्य पता - डेटा अमूर्तता और पदानुक्रम| doi = 10.1145/62139.62141| journal = ACM SIGPLAN Notices| volume = 23| issue = 5| pages = 17–34| date=May 1988 | doi-access = free}}</ref> ओओपीएसएलए 1987 प्रोग्रामिंग लैंग्वेज रिसर्च कॉन्फ्रेंस में डेटा अमूर्तता और वर्ग पदानुक्रम पर, [[बारबरा लिस्कोव]] ने निम्नलिखित कहा: यहां जो कुछ चाहिए वह निम्नलिखित प्रतिस्थापन संपत्ति जैसा है: यदि प्रत्येक वस्तु के लिए <math>o_1</math> प्रकार एस का एक वस्तु है <math>o_2</math> प्रकार टी का ऐसा है कि सभी के लिए कार्यक्रम पी को टी के संदर्भ में परिभाषित किया गया है, पी का व्यवहार अपरिवर्तित है <math>o_1</math> प्रतिस्थापित है के लिए <math>o_2</math>, तब एस, टी का एक उपप्रकार है। इस लक्षण वर्णन को तब से व्यापक रूप से लिस्कोव प्रतिस्थापन सिद्धांत। लिस्कोव प्रतिस्थापन सिद्धांत (एलएसपी) के रूप में जाना जाता है। दुर्भाग्य से, चूंकि, इसमें कई मुद्दे हैं। सबसे पहले, अपने मूल सूत्रीकरण में, यह बहुत मजबूत है: हम संभवतः ही कभी चाहते हैं कि एक उपवर्ग का व्यवहार उसके सुपरक्लास के समान हो; सुपरक्लास ऑब्जेक्ट के लिए एक सबक्लास ऑब्जेक्ट को प्रतिस्थापित करना अधिकांशतः प्रोग्राम के व्यवहार को बदलने के इरादे से किया जाता है, चूंकि, यदि व्यवहारिक उपटाइपिंग का सम्मान किया जाता है, तो प्रोग्राम के वांछनीय गुणों को बनाए रखता है। दूसरे, यह विनिर्देशों का कोई उल्लेख नहीं करता है, इसलिए यह गलत पढ़ने को आमंत्रित करता है जहां टाइप एस के कार्यान्वयन की समानता टाइप टी के कार्यान्वयन से की जाती है। यह कई कारणों से समस्याग्रस्त है, एक यह है कि यह सामान्य स्थितियोंका समर्थन नहीं करता है जहां टी है सार और कोई कार्यान्वयन नहीं है। तीसरा, और सबसे सूक्ष्म रूप से, ऑब्जेक्ट-ओरिएंटेड अनिवार्य प्रोग्रामिंग के संदर्भ में यह ठीक से परिभाषित करना कठिनाई है कि किसी दिए गए प्रकार की वस्तुओं पर सार्वभौमिक या अस्तित्वगत रूप से परिमाणित करने या एक वस्तु को दूसरे के लिए स्थानापन्न करने का क्या अर्थ है।<ref name="leavens2015" />ऊपर दिए गए उदाहरण में, हम बैग ऑब्जेक्ट के लिए स्टैक ऑब्जेक्ट को प्रतिस्थापित नहीं कर रहे हैं, हम एकमात्र स्टैक ऑब्जेक्ट को बैग ऑब्जेक्ट के रूप में उपयोग कर रहे हैं।
+डेटा एबस्ट्रैक्शन और क्लास हायरार्कीज पर एक प्रभावशाली कीनोट एड्रेस<ref>{{Cite journal| last1 = Liskov | first1 = B. | authorlink1 = Barbara Liskov| title = मुख्य पता - डेटा अमूर्तता और पदानुक्रम| doi = 10.1145/62139.62141| journal = ACM SIGPLAN Notices| volume = 23| issue = 5| pages = 17–34| date=May 1988 | doi-access = free}}</ref>में, ऊप्सला 1987 प्रोग्रामिंग भाषा अनुसंधान सम्मेलन पर, [[बारबरा लिस्कोव]]ने निम्नलिखित कहा: "यहाँ चाहिए कुछ ऐसा जैसा निम्नलिखित स्थानांतरण गुण हो: अगर प्रत्येक ऑब्जेक्ट o1 के लिए S के प्रकार के एक ऑब्जेक्ट o2 होता है जिसके लिए T के प्रकार के सभी प्रोग्राम P के लिए, P का व्यवहार बदलाव नहीं करता है जब o1 o2 के लिए उपयोग किया जाता है, तो S T का उप-प्रकार है।" यह विशेषण बाद में लिस्कोव प्रतिस्थापन सिद्धांत (एलएसपी) के रूप में जाना जाता है। दुर्भाग्य से, इसमें कई मुद्दे हैं। पहले, इसकी मूल रूप में, यह बहुत मजबूत है: हम धारक वर्ग के व्यवहार को अधिकांशतः उसके उप-वर्ग के व्यवहार से अलग नहीं चाहते हैं; एक उप-वर्ग वस्तु को एक धारक वर्ग वस्तु के लिए बदलना सामान्यतः कार्यक्रम के व्यवहार को बदलने की इच्छा से किया जाता है, चूंकि, यदि व्यवहारी उप-प्रकार का सम्मान किया जाता है, तो इस प्रकार के बदलाव को कार्यक्रम की वांछनीय गुणवत्ताओं को निरंतर रखने वाले तरीके से किया जाता है। दूसरे, इसमें विनिर्देशों का कोई उल्लेख नहीं है, इसलिए यह गलत रीडिंग के लिए निमंत्रित होता है जहां प्रकार S का अंतर्निर्माण प्रकार T के अंतर्निर्माण से समानता की जाती है। इसके कई कारण हैं, एक कारण है कि यह आम स्थिति का समर्थन नहीं करता है जहां T एक अंतर्जात टाइप है और उसका कोई अमल नहीं होता।<ref name="leavens2015" /> तीसरे और सबसे छिपी कमी ओब्जेक्ट-ओरिएंटेड इम्पेरेटिव प्रोग्रामिंग के सन्दर्भ में है कि किसी विशिष्ट टाइप के ऑब्जेक्ट्स पर समग्र या अस्तित्ववादी रूप से किसी दूसरे ऑब्जेक्ट की जगह लेने का विवरण निर्धारित करना कठिनाई होता है, या एक ऑब्जेक्ट को दूसरे के लिए बदलना। ऊपर दिए गए उदाहरण में, हम एक स्टैक ऑब्जेक्ट को एक बैग ऑब्जेक्ट के रूप में उपयोग कर रहे हैं, हम एक स्टैक ऑब्जेक्ट को बैग ऑब्जेक्ट के लिए बदलने नहीं कर रहे हैं।
-में एक साक्षात्कार में, लिस्कोव खुद बताते हैं कि उन्होंने अपने मुख्य भाषण में जो प्रस्तुत किया वह एक अनौपचारिक नियम था, जिसे जीननेट विंग ने बाद में प्रस्तावित किया कि वे यह पता लगाने की प्रयास करते हैं कि इसका क्या अर्थ है, जिसके कारण उनका संयुक्त प्रकाशन हुआ<ref name="liskov1994" />व्यवहार उपप्रकार पर, और वास्तव में तकनीकी रूप से, इसे व्यवहार उपप्रकार कहा जाता है।<ref>{{Cite AV media |last=van Vleck |first=Tom |title=बारबरा लिस्कोव के साथ साक्षात्कार|date=April 20, 2016 |publisher=ACM |url=https://www.youtube.com/watch?v=-Z-17h3jG0A |archive-url=https://ghostarchive.org/varchive/youtube/20211221/-Z-17h3jG0A |archive-date=2021-12-21 |url-status=live}}{{cbignore}}</ref> साक्षात्कार के समय, वह अवधारणाओं पर चर्चा करने के लिए प्रतिस्थापन शब्दावली का उपयोग नहीं करती है।
+में एक साक्षात्कार में, लिस्कोव खुद बताती हैं कि वह जो कुछ उन्होंने अपने कीनोट भाषण में प्रस्तुत किया था, वह एक "गैर-आधिकारिक नियम" था, जिसके बाद जीनेट विंग ने प्रस्ताव किया कि वे "इसका त्रुटिहीन अर्थ क्या हो सकता है उसे तय करने की कोशिश करें", जिससे उनके संयुक्त प्रकाशन<ref name="liskov1994" />पर बहस की गई थी, और वास्तव में "तकनीकी रूप से, इसे ब्यावहारिक सबटाइपिंग कहा जाता है।"<ref>{{Cite AV media |last=van Vleck |first=Tom |title=बारबरा लिस्कोव के साथ साक्षात्कार|date=April 20, 2016 |publisher=ACM |url=https://www.youtube.com/watch?v=-Z-17h3jG0A |archive-url=https://ghostarchive.org/varchive/youtube/20211221/-Z-17h3jG0A |archive-date=2021-12-21 |url-status=live}}{{cbignore}}</ref> साक्षात्कार के समय, उन्होंने इस संबंध में स्थानांतरण शब्दावली का उपयोग नहीं किया है।
 ==टिप्पणियाँ==
@@ Line 32: / Line 32: @@
 *{{cite journal |last=Parkinson |first=Matthew J. |last2=Bierman |first2=Gavin M. |date=January 2008 |title=Separation logic, abstraction and inheritance |journal=ACM SIGPLAN Notices |volume=43 |issue=1 |pages=75-86 |doi=10.1145/1328897.1328451}}
+[[Category:CS1 English-language sources (en)]]
-[[Category: ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]]
-[[Category: Machine Translated Page]]
 [[Category:Created On 02/03/2023]]
+[[Category:Machine Translated Page]]
+[[Category:Pages with script errors]]
+[[Category:Templates Vigyan Ready]]
+[[Category:ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]]

Anonymous

Search

व्यवहार उपप्रकार: Difference between revisions

Namespaces

More

Page actions

Latest revision as of 16:18, 27 April 2023

Contents

व्यवहार उपप्रकार सत्यापित करना

स्थानापन्नता

टिप्पणियाँ

संदर्भ

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

व्यवहार उपप्रकार: Difference between revisions

Latest revision as of 16:18, 27 April 2023

व्यवहार उपप्रकार सत्यापित करना

स्थानापन्नता

टिप्पणियाँ

संदर्भ

Navigation

Wiki tools

Page tools

Other projects

Categories