व्यवहार उपप्रकार

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

यह उदाहरण व्यवहार उपप्रकार का उल्लंघन करता है क्योंकि प्रकार स्टैक क्यू प्रकार का व्यवहार उप प्रकार नहीं है: ऐसा नहीं है कि प्रकार स्टैक (यानी एलआईएफओ व्यवहार) के दस्तावेज़ीकरण द्वारा वर्णित व्यवहार कतार प्रकार के दस्तावेज़ीकरण के साथ अनुपालन करता है (जिसे फीफो व्यवहार की आवश्यकता होती है) .

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

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

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

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

एक पूर्व शर्त पी द्वारा दिया गया एक विधि विनिर्देश_s और एक पश्च शर्त Q_s एक पूर्व शर्त पी द्वारा दिए गए एक से अधिक मजबूत है_t और एक पश्च शर्त Q_t (औपचारिक रूप से: (पी_s, क्यू_s) ⇒ (पी_t, क्यू_t)) अगर पी_s P से कमजोर है_t (यानी पी_t मतलब पी_s) और क्यू_s Q से अधिक शक्तिशाली है_t (यानी क्यू_s क्यू का तात्पर्य है_t). यही है, एक विधि विनिर्देश को मजबूत करना पोस्टकंडिशन को मजबूत करके और पूर्व शर्त को कमजोर करके किया जा सकता है। दरअसल, एक विधि विनिर्देश मजबूत होता है यदि यह पहले से समर्थित इनपुट के आउटपुट पर अधिक विशिष्ट बाधाओं को लागू करता है, या यदि इसे अधिक इनपुट की आवश्यकता होती है।

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

ध्यान दें, हालांकि, एक विनिर्देश को मजबूत करना संभव है ((पी_s, क्यू_s) ⇒ (पी_t, क्यू_t)) पश्च शर्त को मजबूत किए बिना (Q_s ⇏ क्यू_t). निरपेक्ष मान विधि के लिए एक विनिर्देश पर विचार करें जो एक पूर्व शर्त 0 ≤ x और एक पोस्टकंडिशन परिणाम = x निर्दिष्ट करता है। विनिर्देश जो एक पूर्व शर्त सत्य और एक पश्च शर्त परिणाम = |x| निर्दिष्ट करता है इस विनिर्देशन को मजबूत करता है, भले ही पोस्टकंडिशन परिणाम = |x| स्थिति के बाद के परिणाम = x को मजबूत (या कमजोर) नहीं करता है। पूर्व शर्त पी के साथ एक विनिर्देश के लिए आवश्यक शर्त_s और पश्च शर्त Q_s पूर्व शर्त पी के साथ एक विनिर्देश से अधिक मजबूत होना_t और पश्च शर्त Q_t क्या वह पी_s P से कमजोर है_t और क्यू_s या नहीं पी_sQ से अधिक शक्तिशाली है_t या नहीं पी_t. दरअसल, परिणाम = |x| या गलत परिणाम = x या x < 0 को मजबूत करता है।

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

एक प्रभावशाली मुख्य भाषण में ओओपीएसएलए 1987 प्रोग्रामिंग लैंग्वेज रिसर्च कॉन्फ्रेंस में डेटा अमूर्तता और वर्ग पदानुक्रम पर, बारबरा लिस्कोव ने निम्नलिखित कहा: यहां जो कुछ चाहिए वह निम्नलिखित प्रतिस्थापन संपत्ति जैसा है: यदि प्रत्येक वस्तु के लिए $o_{1}$ प्रकार S का एक वस्तु है $o_{2}$ प्रकार T का ऐसा है कि सभी के लिए कार्यक्रम P को T के संदर्भ में परिभाषित किया गया है, P का व्यवहार अपरिवर्तित है $o_{1}$ प्रतिस्थापित है के लिए $o_{2}$, तब S, T का एक उपप्रकार है। इस लक्षण वर्णन को तब से व्यापक रूप से Liskov प्रतिस्थापन सिद्धांत | Liskov प्रतिस्थापन सिद्धांत (LSP) के रूप में जाना जाता है। दुर्भाग्य से, हालांकि, इसमें कई मुद्दे हैं। सबसे पहले, अपने मूल सूत्रीकरण में, यह बहुत मजबूत है: हम शायद ही कभी चाहते हैं कि एक उपवर्ग का व्यवहार उसके सुपरक्लास के समान हो; सुपरक्लास ऑब्जेक्ट के लिए एक सबक्लास ऑब्जेक्ट को प्रतिस्थापित करना अक्सर प्रोग्राम के व्यवहार को बदलने के इरादे से किया जाता है, हालांकि, यदि व्यवहारिक उपटाइपिंग का सम्मान किया जाता है, तो प्रोग्राम के वांछनीय गुणों को बनाए रखता है। दूसरे, यह विनिर्देशों का कोई उल्लेख नहीं करता है, इसलिए यह गलत पढ़ने को आमंत्रित करता है जहां टाइप एस के कार्यान्वयन की तुलना टाइप टी के कार्यान्वयन से की जाती है। यह कई कारणों से समस्याग्रस्त है, एक यह है कि यह सामान्य मामले का समर्थन नहीं करता है जहां टी है सार और कोई कार्यान्वयन नहीं है। तीसरा, और सबसे सूक्ष्म रूप से, ऑब्जेक्ट-ओरिएंटेड अनिवार्य प्रोग्रामिंग के संदर्भ में यह ठीक से परिभाषित करना मुश्किल है कि किसी दिए गए प्रकार की वस्तुओं पर सार्वभौमिक या अस्तित्वगत रूप से परिमाणित करने या एक वस्तु को दूसरे के लिए स्थानापन्न करने का क्या मतलब है।ऊपर दिए गए उदाहरण में, हम बैग ऑब्जेक्ट के लिए स्टैक ऑब्जेक्ट को प्रतिस्थापित नहीं कर रहे हैं, हम केवल स्टैक ऑब्जेक्ट को बैग ऑब्जेक्ट के रूप में उपयोग कर रहे हैं।

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

संदर्भ

• 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.