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

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

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

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

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

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

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

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

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

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

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

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