वर्ग (कंप्यूटर प्रोग्रामिंग): Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 7: Line 7:


== क्लास  बनाम प्रारूप ==
== क्लास  बनाम प्रारूप ==
इसके सबसे आकस्मिक उपयोग में, लोग प्रायः किसी वस्तु के क्लास को संदर्भित करते हैं, लेकिन संकीर्ण रूप से बोलने वाली  वस्तुओं में इंटरफ़ेस टाइप होता है, अर्थात् मेम्बर वेरीएबल के प्रारूप, मेम्बर फ़ंक्शन (विधियों) के हस्ताक्षर, और ये गुण पूर्ण करते हैं। उसी समय, एक क्लास का कार्यान्वयन (विशेष रूप से विधियों का कार्यान्वयन) होता है, और किसी दिए गए कार्यान्वयन के साथ दिए गए प्रारूप की वस्तुओं को बना सकता है।{{sfn|Gamma|Helm|Johnson|Vlissides|1995|p=17}} प्रारूप सिद्धांत के संदर्भ में, एक क्लास एक कार्यान्वयन है{{mdashb}}एक मूर्त [[डेटा संरचना]] और सबरूटीन्स का संग्रह{{mdashb}}जबकि एक प्रारूप एक [[प्रोटोकॉल (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)|प्रोटोकॉल (वस्तु-उन्मुख प्रोग्रामिंग)]] है। विभिन्न (मूर्त) क्लास समान (अमूर्त) प्रारूप की वस्तुओं का उत्पादन कर सकते हैं (प्रारूप प्रणाली के आधार पर); उदाहरण के लिए, प्रारूप {{Mono|Stack}} दो क्लासों के साथ प्रयुक्त किया जा सकता है{{snd}} {{Mono|SmallStack}} (छोटे स्टैक के लिए तेजी से, लेकिन विकृत पैमाने पर) और {{Mono|ScalableStack}} (छोटे स्टैक के लिए अच्छी तरह से लेकिन उच्च ओवरहेड)। इसी तरह, एक क्लास में कई अलग-अलग कंस्ट्रक्टर हो सकते हैं।
इसके सबसे आकस्मिक उपयोग में, लोग प्रायः किसी वस्तु के क्लास को संदर्भित करते हैं, लेकिन संकीर्ण रूप से बोलने वाली  वस्तुओं में इंटरफ़ेस टाइप होता है, अर्थात् मेम्बर वेरीएबल के प्रारूप, मेम्बर फ़ंक्शन (विधियों) के हस्ताक्षर, और ये गुण पूर्ण करते हैं। उसी समय, एक क्लास का कार्यान्वयन (विशेष रूप से विधियों का कार्यान्वयन) होता है, और किसी दिए गए कार्यान्वयन के साथ दिए गए प्रारूप की वस्तुओं को बना सकता है।{{sfn|Gamma|Helm|Johnson|Vlissides|1995|p=17}} प्रारूप सिद्धांत के संदर्भ में, एक क्लास एक कार्यान्वयन है{{mdashb}}एक मूर्त [[डेटा संरचना]] और सबरूटीन्स का संग्रह{{mdashb}}जबकि एक प्रारूप एक [[प्रोटोकॉल (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)|प्रोटोकॉल (वस्तु-उन्मुख प्रोग्रामिंग)]] है। विभिन्न (मूर्त) क्लास समान (अमूर्त) प्रारूप की वस्तुओं का उत्पादन कर सकते हैं (प्रारूप प्रणाली के आधार पर); उदाहरण के लिए, प्रारूप {{Mono|Stack}} दो क्लासेस के साथ प्रयुक्त किया जा सकता है{{snd}} {{Mono|SmallStack}} (छोटे स्टैक के लिए तेजी से, लेकिन विकृत पैमाने पर) और {{Mono|ScalableStack}} (छोटे स्टैक के लिए अच्छी तरह से लेकिन उच्च ओवरहेड)। इसी तरह, एक क्लास में कई अलग-अलग कंस्ट्रक्टर हो सकते हैं।


क्लास प्रारूप सामान्य रूप से संज्ञाओं का प्रतिनिधित्व करते हैं, जैसे कि एक व्यक्ति, स्थान या वस्तु, या कुछ नामांकित, और एक क्लास इनके कार्यान्वयन का प्रतिनिधित्व करता है। उदाहरण के लिए, {{Mono|Banana}} प्रारूप सामान्य रूप से बनाना के गुणों और कार्यक्षमता का प्रतिनिधित्व कर सकता है, जबकि {{Mono|ABCBanana}} और {{Mono|XYZBanana}} क्लासेस बनाना के उत्पादन के तरीकों का प्रतिनिधित्व करेंगी (जैसे, बनाना के आपूर्तिकर्ता या डेटा संरचनाएं और एक वीडियो गेम में बनाना का प्रतिनिधित्व करने और आकर्षित करने के लिए फ़ंक्शन)। {{Mono|ABCBanana}}  क्लास तब विशेष बनाना का उत्पादन कर सकता है:  {{Mono|ABCBanana}} कए इंस्टेंस क्लास  {{Mono|Banana}} प्रारूप की वस्तुएं होंगी। प्रायः एक प्रारूप का केवल एक कार्यान्वयन दिया जाता है, इस  स्थिति  में क्लास का नाम प्रायः प्रारूप के नाम के समान होता है।
क्लास प्रारूप सामान्य रूप से संज्ञाओं का प्रतिनिधित्व करते हैं, जैसे कि एक व्यक्ति, स्थान या वस्तु, या कुछ नामांकित, और एक क्लास इनके कार्यान्वयन का प्रतिनिधित्व करता है। उदाहरण के लिए, {{Mono|Banana}} प्रारूप सामान्य रूप से बनाना के गुणों और कार्यक्षमता का प्रतिनिधित्व कर सकता है, जबकि {{Mono|ABCBanana}} और {{Mono|XYZBanana}} क्लासेस बनाना के उत्पादन के तरीकों का प्रतिनिधित्व करेंगी (जैसे, बनाना के आपूर्तिकर्ता या डेटा संरचनाएं और एक वीडियो गेम में बनाना का प्रतिनिधित्व करने और आकर्षित करने के लिए फ़ंक्शन)। {{Mono|ABCBanana}}  क्लास तब विशेष बनाना का उत्पादन कर सकता है:  {{Mono|ABCBanana}} कए इंस्टेंस क्लास  {{Mono|Banana}} प्रारूप की वस्तुएं होंगी। प्रायः एक प्रारूप का केवल एक कार्यान्वयन दिया जाता है, इस  स्थिति  में क्लास का नाम प्रायः प्रारूप के नाम के समान होता है।
Line 21: Line 21:
{{Main|विधि (कंप्यूटर प्रोग्रामिंग)}}
{{Main|विधि (कंप्यूटर प्रोग्रामिंग)}}


क्लास या उसके उदाहरणों के गतिविधि को मेथड (कंप्यूटर प्रोग्रामिंग) का उपयोग करके परिभाषित किया गया है। विधियाँ सबरूटीन हैं जो वस्तुओं या क्लासों पर काम करने की क्षमता रखती हैं। ये संचालन किसी वस्तु की स्थिति को बदल सकते हैं या इसे एक्सेस करने के तरीके प्रदान कर सकते हैं।{{sfn|Booch|1994|p=86-88}}  कई प्रारूप की विधियाँ सम्मिलित हैं, लेकिन उनके लिए समर्थन भाषाओं में भिन्न होता है। प्रोग्रामर कोड द्वारा कुछ प्रारूप के तरीके बनाए और कॉल किए जाते हैं, जबकि अन्य विशेष तरीके - जैसे कि कंस्ट्रक्टर, डिस्ट्रक्टर्स और रूपांतरण ऑपरेटर - कंपाइलर-उत्पन्न किए गए कोड द्वारा बनाए और कॉल किए जाते हैं। एक भाषा प्रोग्रामर को इन विशेष विधियों को परिभाषित करने और कॉल करने की स्वीकृति भी दे सकती है।<ref>{{cite web|url=http://www.cplusplus.com/doc/tutorial/classes/|title=Classes (I)|work=C++ Language Tutorial|publisher=cplusplus.com|access-date=2012-04-29}}</ref><ref>{{cite web|url=http://www.cplusplus.com/doc/tutorial/classes2/|title=Classes (II)|work=C++ Language Tutorial|publisher=cplusplus.com|access-date=2012-04-29}}</ref>
क्लास या उसके उदाहरणों के गतिविधि को मेथड (कंप्यूटर प्रोग्रामिंग) का उपयोग करके परिभाषित किया गया है। विधियाँ सबरूटीन हैं जो वस्तुओं या क्लासेस पर काम करने की क्षमता रखती हैं। ये संचालन किसी वस्तु की स्थिति को बदल सकते हैं या इसे एक्सेस करने के तरीके प्रदान कर सकते हैं।{{sfn|Booch|1994|p=86-88}}  कई प्रारूप की विधियाँ सम्मिलित हैं, लेकिन उनके लिए समर्थन भाषाओं में भिन्न होता है। प्रोग्रामर कोड द्वारा कुछ प्रारूप के तरीके बनाए और कॉल किए जाते हैं, जबकि अन्य विशेष तरीके - जैसे कि कंस्ट्रक्टर, डिस्ट्रक्टर्स और रूपांतरण ऑपरेटर - कंपाइलर-उत्पन्न किए गए कोड द्वारा बनाए और कॉल किए जाते हैं। एक भाषा प्रोग्रामर को इन विशेष विधियों को परिभाषित करने और कॉल करने की स्वीकृति भी दे सकती है।<ref>{{cite web|url=http://www.cplusplus.com/doc/tutorial/classes/|title=Classes (I)|work=C++ Language Tutorial|publisher=cplusplus.com|access-date=2012-04-29}}</ref><ref>{{cite web|url=http://www.cplusplus.com/doc/tutorial/classes2/|title=Classes (II)|work=C++ Language Tutorial|publisher=cplusplus.com|access-date=2012-04-29}}</ref>




=== क्लास इंटरफ़ेस की अवधारणा ===
=== क्लास इंटरफ़ेस की अवधारणा ===
{{Main|Interface (computing)}}
{{Main|इंटरफ़ेस (कंप्यूटिंग)}}
प्रत्येक क्लास #संरचना और गतिविधि प्रदान करके एक इंटरफ़ेस प्रयुक्त करता है (या महसूस करता है)। संरचना में डेटा और स्थिति होते हैं, और गतिविधि में कोड होते हैं जो निर्दिष्ट करते हैं कि विधियों को कैसे कार्यान्वित किया जाता है।{{sfn|Booch|1994|p=105}} एक अंतरफलक की परिभाषा और उस अंतरफलक के कार्यान्वयन के बीच अंतर है; हालाँकि, यह रेखा कई प्रोग्रामिंग भाषाओं में धुंधली है क्योंकि क्लास घोषणाएँ एक इंटरफ़ेस को परिभाषित और कार्यान्वित करती हैं। हालाँकि, कुछ भाषाएँ ऐसी सुविधाएँ प्रदान करती हैं जो इंटरफ़ेस और कार्यान्वयन को अलग करती हैं। उदाहरण के लिए, एक #अमूर्त_और_कंक्रीट कार्यान्वयन प्रदान किए बिना एक इंटरफ़ेस को परिभाषित कर सकता है।


क्लास वंशानुक्रम का समर्थन करने वाली भाषाएँ भी क्लासेस को उन क्लासों से इंटरफेस प्राप्त करने की स्वीकृति देती हैं जिनसे वे प्राप्त हुए हैं।
प्रत्येक क्लास संरचना और गतिविधि प्रदान करके एक इंटरफ़ेस प्रयुक्त करता है (या कार्यान्वित करता है)। संरचना में डेटा और स्थिति होते हैं, और गतिविधि में कोड होते हैं जो निर्दिष्ट करते हैं कि विधियों को कैसे कार्यान्वित किया जाता है।{{sfn|Booch|1994|p=105}}  इंटरफ़ेस की परिभाषा और उस इंटरफ़ेस के कार्यान्वयन के बीच अंतर है; हालाँकि, यह रेखा कई प्रोग्रामिंग भाषाओं में अस्पष्ट है क्योंकि क्लास घोषणाएँ एक इंटरफ़ेस को परिभाषित और कार्यान्वित करती हैं। हालाँकि, कुछ भाषाएँ ऐसी सुविधाएँ प्रदान करती हैं जो इंटरफ़ेस और कार्यान्वयन को अलग करती हैं। उदाहरण के लिए, अमूर्त क्लास कार्यान्वयन प्रदान किए बिना एक इंटरफ़ेस को परिभाषित कर सकता है।


उदाहरण के लिए, यदि कक्षा ए कक्षा बी से प्राप्त होती है और यदि कक्षा बी इंटरफ़ेस इंटरफ़ेस बी प्रयुक्त करती है तो कक्षा ए इंटरफ़ेस बी द्वारा प्रदान की गई कार्यक्षमता (स्थिरांक और विधियों की घोषणा) को भी प्राप्त करती है।
क्लास इनहेरिटेंस का समर्थन करने वाली भाषाएँ भी क्लासेस को उन क्लासेस से इंटरफेस प्राप्त करने की स्वीकृति देती हैं जिनसे वे प्राप्त हुए हैं।


उन भाषाओं में जो #जानकारी छिपाने और एनकैप्सुलेशन का समर्थन करती हैं, एक क्लास के इंटरफ़ेस को क्लास के अमूर्त्वजनिक सदस्यों का सेट माना जाता है, जिसमें विधियाँ और विशेषताएँ दोनों सम्मिलित हैं (अंतर्निहित [[म्यूटेटर विधि]] के माध्यम से); कोई भी निजी सदस्य या आंतरिक डेटा संरचना बाहरी द्वारा निर्भर होने का इरादा नहीं है <!--client--> कोड और इस प्रारूप इंटरफ़ेस का हिस्सा नहीं हैं।
उदाहरण के लिए, यदि <nowiki>''क्लास A'' ''क्लास B'' से प्राप्त होती है और यदि ''क्लास B'' इंटरफ़ेस ''इंटरफ़ेस B'' प्रयुक्त करती है तो 'क्लास A' 'इंटरफ़ेस B'</nowiki> द्वारा प्रदान की गई कार्यक्षमता (स्थिर और विधियों की घोषणा) को भी प्राप्त करती है।


वस्तु-उन्मुख प्रोग्रामिंग पद्धति <!--is designed in such a way--> निर्देश देता है कि किसी क्लास के किसी भी इंटरफ़ेस का संचालन एक दूसरे से स्वतंत्र होना है। इसका परिणाम एक स्तरित डिज़ाइन में होता है जहाँ एक इंटरफ़ेस के क्लाइंट इंटरफ़ेस में घोषित विधियों का उपयोग करते हैं। एक इंटरफ़ेस क्लाइंट के लिए किसी विशेष क्रम में एक इंटरफ़ेस के संचालन को प्रयुक्त करने की कोई आवश्यकता नहीं रखता है। इस दृष्टिकोण का लाभ यह है कि क्लाइंट कोड यह मान सकता है कि जब भी क्लाइंट उपयोग के लिए इंटरफ़ेस के संचालन उपलब्ध होते हैं  वस्तु तक पहुँच है।<ref>{{Cite book|title=New perspectives computer concepts, 2016. Comprehensive|last=Jamrich|first=Parsons, June|isbn=9781305271616|location=Boston, MA|oclc=917155105|date = 2015-06-22}}</ref> {{Citation needed|reason=Source needed for whole paragraph...this is a rather specific statement about OOP methodology.|date=April 2012}}
अभिगम विनिर्देशक का समर्थन करने वाली भाषाओं में, क्लास के इंटरफ़ेस को क्लास के सार्वजनिक सदस्यों का समूह माना जाता है, जिसमें विधियाँ और विशेषताएँ दोनों सम्मिलित हैं (अंतर्निहित गेट्टर और सेटर विधियों के माध्यम से); कोई भी निजी सदस्य या आंतरिक डेटा संरचना बाहरी कोड पर निर्भर होने का विचार नहीं है और इस प्रकार इंटरफ़ेस का भाग नहीं है।
 
वस्तु-उन्मुख प्रोग्रामिंग पद्धति निर्देश देता है कि किसी क्लास के किसी भी इंटरफ़ेस का संचालन एक दूसरे से स्वतंत्र होना है। इसका परिणाम एक स्तरित डिज़ाइन में होता है जहाँ एक इंटरफ़ेस के क्लाइंट इंटरफ़ेस में घोषित विधियों का उपयोग करते हैं। एक इंटरफ़ेस क्लाइंट के लिए किसी विशेष क्रम में एक इंटरफ़ेस के संचालन को प्रयुक्त करने की कोई आवश्यकता नहीं रखता है। इस दृष्टिकोण का लाभ यह है कि क्लाइंट कोड यह मान सकता है कि जब भी क्लाइंट के पास ऑब्जेक्ट तक अभिगम्य होती है, तो इंटरफ़ेस के संचालन उपयोग के लिए उपलब्ध होते हैं।<ref>{{Cite book|title=New perspectives computer concepts, 2016. Comprehensive|last=Jamrich|first=Parsons, June|isbn=9781305271616|location=Boston, MA|oclc=917155105|date = 2015-06-22}}</ref> {{Citation needed|reason=Source needed for whole paragraph...this is a rather specific statement about OOP methodology.|date=April 2012}}




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


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


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


=== सदस्य पहुंच ===
=== सदस्य अभिगम्यता ===
{{redirect|Private member|other uses|Private members club|and|Private member's bill}}
''निजी सदस्य" यहां पुनर्निर्देशित करता है। अन्य उपयोगों के लिए, निजी सदस्य क्लब और निजी सदस्य का बिल देखें।''
{{Further|Information hiding}}
निम्नलिखित [[पहुँच विनिर्देशक]] का एक सामान्य सेट है:<ref name="JavaAccessControl">{{cite web| url=http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html|title=Controlling Access to Members of a Class|work=The Java Tutorials|publisher=Oracle|access-date=2012-04-19}}</ref>
* प्राइवेट (या क्लास-प्राइवेट) क्लास तक ही पहुँच को प्रतिबंधित करता है। केवल वही विधियाँ जो एक ही क्लास का हिस्सा हैं, निजी सदस्यों तक पहुँच सकती हैं।
* संरक्षित (या क्लास-संरक्षित) क्लास को स्वयं और उसके सभी उपक्लासों को सदस्य तक पहुँचने की स्वीकृति देता है।
* पब्लिक का तात्पर्य है कि कोई भी कोड सदस्य को उसके नाम से एक्सेस कर सकता है।


हालाँकि कई वस्तु-उन्मुख भाषाएँ उपरोक्त एक्सेस स्पेसिफायर का समर्थन करती हैं, <!-- {{Citation needed|reason=This is fairly obvious, but it needs to be cited--could even use a few links even to articles within Wikipedia.|date=April 2012}} -->उनके शब्दार्थ भिन्न हो सकते हैं।
''अधिक जानकारी: जानकारी छुपाना''


वस्तु-उन्मुख डिज़ाइन क्लास इनवेरिएंट्स को प्रयुक्त करने के लिए पब्लिक मेथड इम्प्लीमेंटेशन के सावधानीपूर्वक डिज़ाइन के संयोजन के साथ एक्सेस स्पेसिफायर का उपयोग करता है - ऑब्जेक्ट्स की स्थिति पर प्रतिबंध। एक्सेस स्पेसिफायर का एक सामान्य उपयोग एक क्लास के आंतरिक डेटा को उसके इंटरफ़ेस से अलग करना है: आंतरिक संरचना को निजी बनाया जाता है, जबकि अमूर्त्वजनिक [[एक्सेसर विधि]]यों का उपयोग ऐसे निजी डेटा का निरीक्षण या परिवर्तन करने के लिए किया जा सकता है।
निम्नलिखित [[पहुँच विनिर्देशक|अभिगम्यता विनिर्देशक]] का एक सामान्य समूह है:<ref name="JavaAccessControl">{{cite web| url=http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html|title=Controlling Access to Members of a Class|work=The Java Tutorials|publisher=Oracle|access-date=2012-04-19}}</ref>
* निजी (या क्लास-निजी) क्लास तक ही अभिगम्य को प्रतिबंधित करता है। केवल वही विधियाँ जो एक ही क्लास का भाग हैं, निजी सदस्यों तक अभिगम्य कर सकती हैं।
* संरक्षित (या क्लास-संरक्षित) क्लास को स्वयं और उसके सभी सबक्लास को सदस्य तक अभिगम्यने की स्वीकृति देता है।
* सार्वजनिक का तात्पर्य है कि कोई भी कोड सदस्य को उसके नाम से एक्सेस कर सकता है।


एक्सेस विनिर्देशक आवश्यक रूप से दृश्यता को नियंत्रित नहीं करते हैं, इसमें निजी सदस्य भी क्लाइंट बाहरी कोड के लिए दृश्यमान हो सकते हैं। कुछ भाषाओं में, एक अप्राप्य लेकिन दृश्यमान सदस्य को रन-टाइम पर संदर्भित किया जा सकता है (उदाहरण के लिए, किसी सदस्य फ़ंक्शन से लौटाए गए सूचक द्वारा), लेकिन क्लाइंट कोड से सदस्य के नाम का संदर्भ देकर इसका उपयोग करने का प्रयास किया जाएगा टाइप चेकर द्वारा रोका गया।<ref>{{cite web|url=https://www.securecoding.cert.org/confluence/display/cplusplus/OOP08-CPP.+Do+not+return+references+to+private+data|title=OOP08-CPP. Do not return references to private data|work=CERT C++ Secure Coding Standard|publisher=Carnegie Mellon University|date=2010-05-10|access-date=2012-05-07|archive-url=https://web.archive.org/web/20151003162754/https://www.securecoding.cert.org/confluence/display/cplusplus/OOP08-CPP.+Do+not+return+references+to+private+data|archive-date=2015-10-03|url-status=dead}}</ref>
हालाँकि कई वस्तु-उन्मुख भाषाएँ उपरोक्त एक्सेस विनिर्देशक का समर्थन करती हैं, उनके सिमैन्टिक भिन्न हो सकते हैं।
विभिन्न वस्तु-उन्मुख प्रोग्रामिंग भाषा सदस्य की पहुंच और दृश्यता को विभिन्न डिग्री तक प्रयुक्त करती हैं, और भाषा के प्रारूप सिस्टम और संकलन नीतियों के आधार पर, [[संकलन समय]] | कंपाइल-टाइम या [[रन टाइम (कार्यक्रम जीवनचक्र चरण)|रन टाइम (कार्यक्रम जीवनचक्र वेरीएबलण)]] | रन-टाइम पर प्रयुक्त होती हैं। उदाहरण के लिए, [[जावा (प्रोग्रामिंग भाषा)]] भाषा क्लाइंट कोड की स्वीकृति नहीं देती है जो किसी क्लास के निजी डेटा को कंपाइल करने के लिए एक्सेस करता है।
 
<ref>{{cite web|url=http://introcs.cs.princeton.edu/java/11cheatsheet/errors.pdf |archive-url=https://web.archive.org/web/20111018094803/http://introcs.cs.princeton.edu/java/11cheatsheet/errors.pdf |archive-date=2011-10-18 |url-status=live|title=2.2 Identifiers|work=Compile and Runtime Errors in Java|first=Mordechai|last=Ben-Ari|date=2007-01-24|access-date=2012-05-07}}</ref> <!-- whereas in languages like [[Objective-C]] or [[Perl]] client code is not restricted.--> [[सी ++]] भाषा में, निजी तरीके दिखाई देते हैं, लेकिन इंटरफ़ेस में पहुंच योग्य नहीं हैं; हालाँकि, उन्हें पूरी तरह से अमूर्त क्लासों को स्पष्ट रूप से घोषित करके अदृश्य बनाया जा सकता है जो कक्षा के इंटरफेस का प्रतिनिधित्व करते हैं।<ref name="cppinterface">{{cite web|url=http://www.drdobbs.com/cpp/184410630|title=C++ Interfaces|last=Wild|first=Fred|work=Dr. Dobb's|publisher=UBM Techweb|access-date=2012-05-02}}</ref>
वस्तु-उन्मुख डिज़ाइन ऑब्जेक्ट्स की स्थिति पर प्रतिबंध क्लास इनवेरिएंट्स को प्रयुक्त करने के लिए सार्वजनिक मेथड (विधि) कार्यान्वयन के सावधानीपूर्वक डिज़ाइन के संयोजन के साथ एक्सेस विनिर्देशक का उपयोग करता है। एक्सेस विनिर्देशक का एक सामान्य उपयोग एक क्लास के आंतरिक डेटा को उसके इंटरफ़ेस से अलग करना है: आंतरिक संरचना को निजी बनाया जाता है, जबकि सार्वजनिक [[एक्सेसर विधि]]यों का उपयोग ऐसे निजी डेटा का निरीक्षण या परिवर्तन करने के लिए किया जा सकता है।
कुछ भाषाओं में अन्य पहुँच-योग्यता योजनाएँ हैं:
 
* इंस्टेंस बनाम क्लास एक्सेसिबिलिटी: [[रूबी (प्रोग्रामिंग भाषा)]] क्रमशः क्लास-प्राइवेट और क्लास-प्रोटेक्टेड के बदले इंस्टेंस-प्राइवेट और इंस्टेंस-प्रोटेक्टेड एक्सेस स्पेसिफायर का समर्थन करती है। वे इसमें भिन्न हैं कि वे उदाहरण के क्लास के अतिरिक्त उदाहरण के आधार पर ही पहुंच को प्रतिबंधित करते हैं।<ref>{{cite web | url=http://ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html | title=Classes, Objects, and Variables|work=Programming Ruby: The Pragmatic Programmer's Guide | last1=Thomas | last2=Hunt | publisher=Ruby-Doc.org | access-date=2012-04-26}}
एक्सेस विनिर्देशक आवश्यक रूप से दृश्यता को नियंत्रित नहीं करते हैं, इसमें निजी सदस्य भी क्लाइंट बाहरी कोड के लिए दृश्यमान हो सकते हैं। कुछ भाषाओं में, एक अप्राप्य लेकिन दृश्यमान सदस्य को रन-टाइम पर संदर्भित किया जा सकता है (उदाहरण के लिए, किसी सदस्य फ़ंक्शन से प्रतिवृत किए गए पॉइन्टर द्वारा), लेकिन क्लाइंट कोड से सदस्य के नाम का संदर्भ देकर इसका उपयोग करने का प्रयास किया जाएगा टाइप चेकर द्वारा रोका गया।<ref>{{cite web|url=https://www.securecoding.cert.org/confluence/display/cplusplus/OOP08-CPP.+Do+not+return+references+to+private+data|title=OOP08-CPP. Do not return references to private data|work=CERT C++ Secure Coding Standard|publisher=Carnegie Mellon University|date=2010-05-10|access-date=2012-05-07|archive-url=https://web.archive.org/web/20151003162754/https://www.securecoding.cert.org/confluence/display/cplusplus/OOP08-CPP.+Do+not+return+references+to+private+data|archive-date=2015-10-03|url-status=dead}}</ref>
 
विभिन्न वस्तु-उन्मुख प्रोग्रामिंग भाषा सदस्य की अभिगम्य और दृश्यता को विभिन्न सीमा तक प्रयुक्त करती हैं, और भाषा के प्रारूप सिस्टम और संकलन नीतियों के आधार पर, कंपाइल-टाइम या [[रन टाइम (कार्यक्रम जीवनचक्र चरण)|रन टाइम]] पर प्रयुक्त होती हैं। उदाहरण के लिए, [[जावा (प्रोग्रामिंग भाषा)]] भाषा क्लाइंट कोड की स्वीकृति नहीं देती है जो किसी क्लास के निजी डेटा को कंपाइल करने के लिए एक्सेस करता है।<ref>{{cite web|url=http://introcs.cs.princeton.edu/java/11cheatsheet/errors.pdf |archive-url=https://web.archive.org/web/20111018094803/http://introcs.cs.princeton.edu/java/11cheatsheet/errors.pdf |archive-date=2011-10-18 |url-status=live|title=2.2 Identifiers|work=Compile and Runtime Errors in Java|first=Mordechai|last=Ben-Ari|date=2007-01-24|access-date=2012-05-07}}</ref> [[सी ++|C ++]] भाषा में, निजी तरीके दिखाई देते हैं, लेकिन इंटरफ़ेस में अभिगम्य योग्य नहीं हैं; हालाँकि, उन्हें पूरी तरह से अमूर्त क्लासेस को स्पष्ट रूप से घोषित करके अदृश्य बनाया जा सकता है जो क्लास के इंटरफेस का प्रतिनिधित्व करते हैं।<ref name="cppinterface">{{cite web|url=http://www.drdobbs.com/cpp/184410630|title=C++ Interfaces|last=Wild|first=Fred|work=Dr. Dobb's|publisher=UBM Techweb|access-date=2012-05-02}}</ref> कुछ भाषाओं में अन्य अभिगम्य-योग्यता योजनाएँ हैं:
* इंस्टेंस बनाम क्लास अभिगम्यता: [[रूबी (प्रोग्रामिंग भाषा)]] क्रमशः क्लास-निजी और क्लास-प्रोटेक्टेड के बदले इंस्टेंस-निजी और इंस्टेंस-संरक्षित एक्सेस विनिर्देशक का समर्थन करती है। वे इसमें भिन्न हैं कि वे उदाहरण के क्लास के अतिरिक्त उदाहरण के आधार पर ही अभिगम्य को प्रतिबंधित करते हैं।<ref>{{cite web | url=http://ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html | title=Classes, Objects, and Variables|work=Programming Ruby: The Pragmatic Programmer's Guide | last1=Thomas | last2=Hunt | publisher=Ruby-Doc.org | access-date=2012-04-26}}
</ref>
</ref>
* मित्र: सी ++ एक तंत्र का समर्थन करता है जहां स्पष्ट रूप से क्लास के मित्र कार्य के रूप में घोषित एक फ़ंक्शन निजी या संरक्षित के रूप में नामित सदस्यों तक पहुंच सकता है।<ref>{{cite web|url=http://www.cplusplus.com/doc/tutorial/inheritance/
* पक्ष समर्थक: C ++ एक तंत्र का समर्थन करता है जहां स्पष्ट रूप से क्लास के पक्ष समर्थक फ़ंक्शन के रूप में घोषित एक फ़ंक्शन निजी या संरक्षित के रूप में नामित सदस्यों तक अभिगम्य सकता है।<ref>{{cite web|url=http://www.cplusplus.com/doc/tutorial/inheritance/
|title=Friendship and inheritance|work=C++ Language Tutorial|publisher=cplusplus.com|access-date=2012-04-26}}</ref>
|title=Friendship and inheritance|work=C++ Language Tutorial|publisher=cplusplus.com|access-date=2012-04-26}}</ref>
* पथ-आधारित: जावा एक जावा सिंटैक्स # एक्सेस संशोधक के अंदरएक सदस्य तक पहुंच को प्रतिबंधित करने का समर्थन करता है, जो फ़ाइल का तार्किक पथ है। हालाँकि, संरक्षित सदस्यों तक पहुँचने के लिए रूपरेखा क्लास के समान पैकेज में क्लासेस को प्रयुक्त करने के लिए जावा रूपरेखा का विस्तार करना एक सामान्य अभ्यास है। स्रोत फ़ाइल पूरी तरह से अलग स्थान पर सम्मिलित हो सकती है, और एक अलग .jar फ़ाइल में तैनात की जा सकती है, फिर भी जहाँ तक JVM का संबंध है, उसी तार्किक पथ में हो।<ref name=JavaAccessControl />
* पथ-आधारित: जावा एक जावा सिंटैक्स एक्सेस संशोधक के अंदर एक सदस्य तक अभिगम्य को प्रतिबंधित करने का समर्थन करता है, जो फ़ाइल का तार्किक पथ है। हालाँकि, संरक्षित सदस्यों तक अभिगम्य के लिए रूपरेखा क्लास के समान पैकेज में क्लासेस को प्रयुक्त करने के लिए जावा रूपरेखा का विस्तार करना एक सामान्य अभ्यास है। स्रोत फ़ाइल पूरी तरह से अलग स्थान पर सम्मिलित हो सकती है, और एक अलग .jar फ़ाइल में परिनियोजित की जा सकती है, फिर भी जहाँ तक जावा वर्चुअल मशीन का संबंध है, उसी तार्किक पथ में हो।<ref name="JavaAccessControl" />




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


=== रचना ===
=== रचना ===
क्लासेस को अन्य क्लासों से बनाया जा सकता है, जिससे संलग्न क्लास और उसके एम्बेडेड क्लासों के बीच [[एक]] रचनात्मक संबंध स्थापित किया जा सकता है। क्लासों के बीच रचनात्मक संबंध को सामान्य रूप से है-संबंध के रूप में भी जाना जाता है।{{sfn|Booch|1994|p=180}} उदाहरण के लिए, एक क्लास कार से बना हो सकता है और इसमें एक क्लास इंजन हो सकता है। इसलिए, एक कार में एक इंजन होता है। रचना का एक रूपरूप रोकथाम है, जो कि उनके पास सम्मिलित उदाहरण द्वारा घटक उदाहरणों का परिक्षेत्र है। यदि एक संलग्न वस्तु में मूल्य के अनुअमूर्त घटक उदाहरण होते हैं, तो घटक और उनके संलग्न वस्तु का एक समान [[वस्तु जीवनकाल]] होता है। यदि घटक संदर्भ द्वारा समाहित हैं, तो हो सकता है कि उनका जीवनकाल समान न हो।{{sfn|Booch|1994|p=128-129}} उदाहरण के लिए, ऑब्जेक्टिव-सी 2.0 में:
क्लासेस को अन्य क्लासेस से बनाया जा सकता है, जिससे संलग्न क्लास और उसके एम्बेडेड क्लासेस के बीच [[एक]] रचनात्मक संबंध स्थापित किया जा सकता है। क्लासेस के बीच रचनात्मक संबंध को सामान्य रूप से है-a संबंध के रूप में भी जाना जाता है।{{sfn|Booch|1994|p=180}} उदाहरण के लिए, एक क्लास रजिस्टर संख्या के एड्रैस वाले भाग की सामग्री से बना हो सकता है और इसमें एक क्लास इंजन हो सकता है। इसलिए, एक रजिस्टर संख्या के एड्रैस वाले भाग की सामग्री में एक इंजन होता है। रचना का एक स्वरूप नियंत्रण है, जो कि उनके पास सम्मिलित उदाहरण द्वारा घटक इंस्टेंस का परिक्षेत्र है। यदि एक संलग्न वस्तु में मूल्य के अमूर्त घटक इंस्टेंस होते हैं, तो घटक और उनके संलग्न वस्तु [[वस्तु जीवनकाल|वस्तु का जीवनकाल]] समान होता है। यदि घटक संदर्भ द्वारा समाहित हैं, तो हो सकता है कि उनका जीवनकाल समान न हो।{{sfn|Booch|1994|p=128-129}} उदाहरण के लिए, ऑब्जेक्टिव-सी 2.0 में:
  @interface Car : NSObject
  @interface Car : NSObject
   
   
Line 79: Line 81:
   
   
  @end
  @end
 
यह {{Mono|Car}} क्लास का एक इंस्टेंस  {{Mono|NSString}} (एक [[स्ट्रिंग (कंप्यूटर विज्ञान)]] वस्तु), {{Mono|Engine}}, और {{Mono|NSArray}} (एक सरणी ऑब्जेक्ट) का एक उदाहरण है।
यह {{Mono|Car}} क्लास का एक उदाहरण है {{Mono|NSString}} (एक [[स्ट्रिंग (कंप्यूटर विज्ञान)]] वस्तु), {{Mono|Engine}}, और {{Mono|NSArray}} (एक सरणी वस्तु)


=== श्रेणीबद्ध ===
=== श्रेणीबद्ध ===
क्लासेस एक या एक से अधिक सम्मिलिता क्लासों से प्राप्त की जा सकती हैं, जिससे व्युत्पन्न-क्लासों (आधार क्लास, मूल क्लास या) के बीच एक श्रेणीबद्ध संबंध स्थापित किया जा सकता है{{vanchor|superclasses|SUPERCLASS}}) और व्युत्पन्न क्लास (बाल क्लास या उपक्लास)डिराइव्ड क्लास और डिराइव्ड-फ्रॉम क्लास के संबंध को सामान्य रूप से 'इज़-ए' रिलेशनशिप के रूप में जाना जाता है।{{sfn|Booch|1994|p=112}} उदाहरण के लिए, एक क्लास 'बटन' क्लास 'नियंत्रण' से प्राप्त किया जा सकता है। इसलिए, एक बटन एक नियंत्रण है। मूल क्लास के संरचनात्मक और गतिविधििक सदस्यों को बाल क्लास द्वारा ''विरासत में'' दिया जाता है। व्युत्पन्न क्लास उन अतिरिक्त संरचनात्मक सदस्यों (डेटा क्षेत्र्स) और गतिविधििक सदस्यों (विधियों) को परिभाषित कर सकते हैं, जिनके अलावा वे ''विरासत'' हैं और इसलिए उनके सुपरक्लास के ''विशेषज्ञता'' हैं। साथ ही, यदि भाषा स्वीकृति देती है तो व्युत्पन्न क्लासेस विरासत में मिली विधियों को ओवरराइड कर सकती हैं।
क्लासेस एक या एक से अधिक सम्मिलित क्लासेस से प्राप्त की जा सकती हैं, जिससे व्युत्पन्न-क्लासेस (बेस क्लास, पैरेंट क्लास या {{vanchor|superclasses|SUPERCLASS}}) के बीच एक श्रेणीबद्ध संबंध  और व्युत्पन्न क्लास (चाइल्ड क्लास या सबक्लास) स्थापित किया जा सकता है। डिराइव्ड क्लास और डिराइव्ड-फ्रॉम क्लास के संबंध को सामान्य रूप से 'इज़-ए' रिलेशनशिप के रूप में जाना जाता है।{{sfn|Booch|1994|p=112}} उदाहरण के लिए, एक क्लास 'बटन' क्लास 'नियंत्रण' से प्राप्त किया जा सकता है। इसलिए, एक बटन एक नियंत्रण है। पैरेंट क्लास के संरचनात्मक और गतिविधििक सदस्यों को चाइल्ड क्लास द्वारा ''इनहेरिटेंस में'' दिया जाता है। व्युत्पन्न क्लास उन अतिरिक्त संरचनात्मक सदस्यों (डेटा क्षेत्र्स) और गतिविधििक सदस्यों (विधियों) को परिभाषित कर सकते हैं, जिनके अतिरिक्त वे ''इनहेरिटेंस'' हैं और इसलिए उनके सुपरक्लास के ''विशेषज्ञता'' हैं। साथ ही, यदि भाषा स्वीकृति देती है तो व्युत्पन्न क्लासेस इनहेरिटेंस में मिली विधियों को ओवरराइड कर सकती हैं।


सभी भाषाएँ एकाधिक वंशानुक्रम का समर्थन नहीं करती हैं। उदाहरण के लिए, जावा एक क्लास को कई इंटरफेस प्रयुक्त करने की स्वीकृति देता है, लेकिन केवल एक क्लास से प्राप्त होता है।<ref name="javainterface">{{cite web| url=http://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html|title=इंटरफेस|work=The Java Tutorials|publisher=Oracle|access-date=2012-05-01}}</ref> यदि एकाधिक वंशानुक्रम की स्वीकृति है, तो पदानुक्रम एक निर्देशित चक्रीय ग्राफ (या संक्षेप में DAG) है, अन्यथा यह एक [[पेड़ (ग्राफ सिद्धांत)]] है। पदानुक्रम में नोड्स के रूप में क्लासेस और लिंक के रूप में वंशानुक्रम संबंध हैं। विभिन्न स्तरों की क्लासेस की तुलना में एक ही स्तर की क्लासेस [[एसोसिएशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)|एसोसिएशन (वस्तु-उन्मुख प्रोग्रामिंग)]] होने की अधिक संभावना है। इस पदानुक्रम के स्तरों को लेयर (वस्तु-उन्मुख डिज़ाइन) या [[अमूर्तता का स्तर]] कहा जाता है।
सभी भाषाएँ एकाधिक इनहेरिटेंस का समर्थन नहीं करती हैं। उदाहरण के लिए, जावा एक क्लास को कई इंटरफेस प्रयुक्त करने की स्वीकृति देता है, लेकिन केवल एक क्लास से प्राप्त होता है।<ref name="javainterface">{{cite web| url=http://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html|title=इंटरफेस|work=The Java Tutorials|publisher=Oracle|access-date=2012-05-01}}</ref> यदि एकाधिक इनहेरिटेंस की स्वीकृति है, तो पदानुक्रम एक निर्देशित चक्रीय ग्राफ (या संक्षेप में DAG) है, अन्यथा यह एक [[पेड़ (ग्राफ सिद्धांत)]] है। पदानुक्रम में नोड्स के रूप में क्लासेस और लिंक के रूप में इनहेरिटेंस संबंध हैं। विभिन्न स्तरों की क्लासेस की तुलना में एक ही स्तर की क्लासेस [[एसोसिएशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)|एसोसिएशन (वस्तु-उन्मुख प्रोग्रामिंग)]] होने की अधिक संभावना है। इस पदानुक्रम के स्तरों को लेयर (वस्तु-उन्मुख डिज़ाइन) या [[अमूर्तता का स्तर]] कहा जाता है।


उदाहरण (आईफोन एसडीके से सरलीकृत उद्देश्य-सी 2.0 कोड):
उदाहरण (आईफोन एसडीके से सरलीकृत उद्देश्य-सी 2.0 कोड):
Line 94: Line 95:
इस उदाहरण में, एक UITableView एक UIScrollView है एक UIView एक UIResponder एक NSObject है।
इस उदाहरण में, एक UITableView एक UIScrollView है एक UIView एक UIResponder एक NSObject है।


==== उपक्लास की परिभाषाएँ ====
==== सबक्लास की परिभाषाएँ ====
{{Main|Inheritance (object-oriented programming)|Superclass (computer science)|Subclass (computer science)}}
{{Main|Inheritance (object-oriented programming)|Superclass (computer science)|Subclass (computer science)}}
संकल्पनात्मक रूप से, एक सुपरक्लास अपने उपक्लासों का [[सुपरसेट]] है। उदाहरण के लिए, एक सामान्य क्लास पदानुक्रम सम्मिलित होगा {{Mono|GraphicObject}} के सुपरक्लास के रूप में {{Mono|Rectangle}} और {{Mono|Ellipse}}, जबकि {{Mono|Square}} का एक उपक्लास होगा {{Mono|Rectangle}}. ये सभी समुच्चय सिद्धांत में भी उपसमुच्चय हैं, अर्थात, सभी क्लास आयत हैं लेकिन सभी आयत क्लास नहीं हैं।
संकल्पनात्मक रूप से, एक सुपरक्लास अपने सबक्लासेस का [[सुपरसेट]] है। उदाहरण के लिए, एक सामान्य क्लास पदानुक्रम सम्मिलित होगा {{Mono|GraphicObject}} के सुपरक्लास के रूप में {{Mono|Rectangle}} और {{Mono|Ellipse}}, जबकि {{Mono|Square}} का एक सबक्लास होगा {{Mono|Rectangle}}. ये सभी समुच्चय सिद्धांत में भी उपसमुच्चय हैं, अर्थात, सभी क्लास आयत हैं लेकिन सभी आयत क्लास नहीं हैं।


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


[[वस्तु-उन्मुख मॉडलिंग]] में इस प्रारूप के संबंध सामान्य रूप से ऑब्जेक्ट गुणों के रूप में तैयार किए जाते हैं। इस उदाहरण में, {{Mono|Car}} क्लास में एक गुण होगी {{Mono|parts}}. {{Mono|parts}} वस्तुओं का एक संग्रह रखने के लिए टाइप किया जाएगा, जैसे कि उदाहरण {{Mono|Body}}, {{Mono|Engine}}, {{Mono|Tires}}, वगैरह।
[[वस्तु-उन्मुख मॉडलिंग]] में इस प्रारूप के संबंध सामान्य रूप से ऑब्जेक्ट गुणों के रूप में तैयार किए जाते हैं। इस उदाहरण में, {{Mono|Car}} क्लास में एक गुण होगी {{Mono|parts}}. {{Mono|parts}} वस्तुओं का एक संग्रह रखने के लिए टाइप किया जाएगा, जैसे कि उदाहरण {{Mono|Body}}, {{Mono|Engine}}, {{Mono|Tires}}, वगैरह।
ऑब्जेक्ट मॉडलिंग भाषा जैसे कि यूनिफाइड मॉडलिंग भाषा में भाग और अन्य प्रारूप के संबंधों के विभिन्न पहलुओं को मॉडल करने की क्षमता सम्मिलित है - डेटा जैसे कि वस्तुओं की प्रमुखता, इनपुट और आउटपुट मूल्यों पर बाधाएं, आदि। इस जानकारी का उपयोग डेवलपर टूल द्वारा किया जा सकता है वस्तुओं के लिए मूल डेटा परिभाषाओं के साथ अतिरिक्त कोड उत्पन्न करें, जैसे कि म्यूटेटर विधि पर त्रुटि जाँच।<ref>{{cite web|title=UML-to-Java transformation in IBM Rational Software Architect editions and related software|url=http://www.ibm.com/developerworks/rational/library/08/1202_berfeld/|publisher=[[IBM]]|date=2 December 2008|first=Marya|last=Berfeld|access-date=20 December 2013}}</ref>
ऑब्जेक्ट मॉडलिंग भाषा जैसे कि यूनिफाइड मॉडलिंग भाषा में भाग और अन्य प्रारूप के संबंधों के विभिन्न पहलुओं को मॉडल करने की क्षमता सम्मिलित है - डेटा जैसे कि वस्तुओं की प्रमुखता, इनपुट और आउटपुट मूल्यों पर बाधाएं, आदि। इस जानकारी का उपयोग विकासक टूल द्वारा किया जा सकता है वस्तुओं के लिए मूल डेटा परिभाषाओं के साथ अतिरिक्त कोड उत्पन्न करें, जैसे कि म्यूटेटर विधि पर त्रुटि जाँच।<ref>{{cite web|title=UML-to-Java transformation in IBM Rational Software Architect editions and related software|url=http://www.ibm.com/developerworks/rational/library/08/1202_berfeld/|publisher=[[IBM]]|date=2 December 2008|first=Marya|last=Berfeld|access-date=20 December 2013}}</ref>
ऑब्जेक्ट क्लास सिस्टम को मॉडलिंग और कार्यान्वित करते समय एक महत्वपूर्ण सवाल यह है कि क्या एक क्लास में एक या एक से अधिक सुपरक्लास हो सकते हैं। वास्तविक दुनिया में वास्तविक सेट के साथ ऐसा सेट मिलना दुर्लभ होगा जो एक से अधिक अन्य सेट के साथ नहीं मिला हो। हालाँकि, जबकि कुछ प्रणालियाँ जैसे फ्लेवर और सीएलओएस एक से अधिक माता-पिता को रन टाइम पर ऐसा करने की क्षमता प्रदान करते हैं, जटिलता का परिचय देते हैं कि वस्तु-उन्मुख समुदाय में कई लोग पहली बार में ऑब्जेक्ट क्लास का उपयोग करने के लक्ष्यों के लिए विरोधाभासी मानते हैं। एक से अधिक सुपरक्लास के साथ काम करते समय यह समझना जटिल हो सकता है कि संदेश को संभालने के लिए कौन सी कक्षा जिम्मेदार होगी। यदि लापरवाही से उपयोग किया जाता है तो यह सुविधा उसी प्रणाली की कुछ जटिलताओं को पेश कर सकती है और अस्पष्टता क्लासों से बचने के लिए डिज़ाइन की गई थी।<ref>{{cite book|last=Jacobsen|first=Ivar|title=Object Oriented Software Engineering|year=1992|publisher=Addison-Wesley ACM Press|isbn=0-201-54435-0|pages=[https://archive.org/details/objectorientedso00jaco/page/43 43–69]|author2=Magnus Christerson|author3=Patrik Jonsson|author4=Gunnar Overgaard|url=https://archive.org/details/objectorientedso00jaco/page/43}}</ref>
ऑब्जेक्ट क्लास सिस्टम को मॉडलिंग और कार्यान्वित करते समय एक महत्वपूर्ण सवाल यह है कि क्या एक क्लास में एक या एक से अधिक सुपरक्लास हो सकते हैं। वास्तविक दुनिया में वास्तविक सेट के साथ ऐसा सेट मिलना दुर्लभ होगा जो एक से अधिक अन्य सेट के साथ नहीं मिला हो। हालाँकि, जबकि कुछ प्रणालियाँ जैसे फ्लेवर और सीएलओएस एक से अधिक माता-पिता को रन टाइम पर ऐसा करने की क्षमता प्रदान करते हैं, जटिलता का परिचय देते हैं कि वस्तु-उन्मुख समुदाय में कई लोग पहली बार में ऑब्जेक्ट क्लास का उपयोग करने के लक्ष्यों के लिए विरोधाभासी मानते हैं। एक से अधिक सुपरक्लास के साथ काम करते समय यह समझना जटिल हो सकता है कि संदेश को संभालने के लिए कौन सी क्लास जिम्मेदार होगी। यदि लापरवाही से उपयोग किया जाता है तो यह सुविधा उसी प्रणाली की कुछ जटिलताओं को पेश कर सकती है और अस्पष्टता क्लासेस से बचने के लिए डिज़ाइन की गई थी।<ref>{{cite book|last=Jacobsen|first=Ivar|title=Object Oriented Software Engineering|year=1992|publisher=Addison-Wesley ACM Press|isbn=0-201-54435-0|pages=[https://archive.org/details/objectorientedso00jaco/page/43 43–69]|author2=Magnus Christerson|author3=Patrik Jonsson|author4=Gunnar Overgaard|url=https://archive.org/details/objectorientedso00jaco/page/43}}</ref>
अधिकांश आधुनिक वस्तु-उन्मुख भाषाओं जैसे कि स्मॉलटाक और जावा को रन टाइम पर एकल वंशानुक्रम की आवश्यकता होती है। इन भाषाओं के लिए, एकाधिक विरासत मॉडलिंग के लिए उपयोगी हो सकती है लेकिन कार्यान्वयन के लिए नहीं।
अधिकांश आधुनिक वस्तु-उन्मुख भाषाओं जैसे कि स्मॉलटाक और जावा को रन टाइम पर एकल इनहेरिटेंस की आवश्यकता होती है। इन भाषाओं के लिए, एकाधिक इनहेरिटेंस मॉडलिंग के लिए उपयोगी हो सकती है लेकिन कार्यान्वयन के लिए नहीं।


हालाँकि, [[सेमांटिक वेब]] एप्लिकेशन ऑब्जेक्ट्स में कई सुपरक्लास होते हैं। इंटरनेट की अस्थिरता के लिए इस स्तर के लचीलेपन की आवश्यकता होती है और तकनीकी मानकों जैसे कि [[वेब ओन्टोलॉजी भाषा]] | वेब ओन्टोलॉजी भाषा (OWL) को इसका समर्थन करने के लिए डिज़ाइन किया गया है।
हालाँकि, [[सेमांटिक वेब]] एप्लिकेशन ऑब्जेक्ट्स में कई सुपरक्लास होते हैं। इंटरनेट की अस्थिरता के लिए इस स्तर के लचीलेपन की आवश्यकता होती है और तकनीकी मानकों जैसे कि [[वेब ओन्टोलॉजी भाषा]] | वेब ओन्टोलॉजी भाषा (OWL) को इसका समर्थन करने के लिए डिज़ाइन किया गया है।
Line 110: Line 111:




=== क्लास अवधारणा और वंशानुक्रम की रूढ़िवादिता ===
=== क्लास अवधारणा और इनहेरिटेंस की रूढ़िवादिता ===
हालाँकि क्लास-आधारित भाषाओं को सामान्य रूप से वंशानुक्रम का समर्थन करने के लिए माना जाता है, वंशानुक्रम क्लासों की अवधारणा का एक आंतरिक रूपरूप नहीं है। कुछ भाषाएँ, जिन्हें प्रायः [[वस्तु-आधारित भाषाएँ]] कहा जाता है, क्लासेस का समर्थन करती हैं, फिर भी वंशानुक्रम का समर्थन नहीं करती हैं। वस्तु-आधारित भाषाओं के उदाहरणों में [[मूल दृश्य]] के पुराने संस्करण सम्मिलित हैं।<!-- do not provide the structural benefits of statically type-checked interfaces for objects. This is because in object-based languages, it is possible to use and extend data structures and attach methods to them at run-time. This precludes the compiler or interpreter being able to check the type information specified in the source code as the type is built dynamically and not defined statically. Most of these languages allow for ''instance behavior'' and complex ''operational polymorphism'' (see [[dynamic dispatch]] and [[Polymorphism (computer science)|polymorphism]]). -->
हालाँकि क्लास-आधारित भाषाओं को सामान्य रूप से इनहेरिटेंस का समर्थन करने के लिए माना जाता है, इनहेरिटेंस क्लासेस की अवधारणा का एक आंतरिक स्वरूप नहीं है। कुछ भाषाएँ, जिन्हें प्रायः [[वस्तु-आधारित भाषाएँ]] कहा जाता है, क्लासेस का समर्थन करती हैं, फिर भी इनहेरिटेंस का समर्थन नहीं करती हैं। वस्तु-आधारित भाषाओं के उदाहरणों में [[मूल दृश्य]] के पुराने संस्करण सम्मिलित हैं।




=== वस्तु-उन्मुख विश्लेषण के भीतर <!-- belongs in an Object-Oriented Analysis article--> ===
 
{{Main|Association (object-oriented programming)}}<!--consider moving a bunch of stuff here to this page...-->
=== वस्तु-उन्मुख विश्लेषण के भीतर ===
[[वस्तु-उन्मुख विश्लेषण और डिजाइन]]|वस्तु-उन्मुख एनालिसिस और [[एकीकृत मॉडलिंग भाषा]] में, दो क्लासों के बीच एक जुड़ाव क्लासेस या उनके संबंधित उदाहरणों के बीच सहयोग का प्रतिनिधित्व करता है। संघों की दिशा है; उदाहरण के लिए, दो क्लासों के बीच एक द्वि-दिशात्मक जुड़ाव इंगित करता है कि दोनों क्लास अपने संबंधों से अवगत हैं।<ref name="ibmuml">{{cite web| url=http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/|title=UML Basics: The class diagram|last=Bell|first=Donald|work=developer Works|publisher=IBM|access-date=2012-05-02}}</ref> संघों को उनके नाम या उद्देश्य के अनुअमूर्त लेबल किया जा सकता है।{{sfn|Booch|1994|p=179}}
{{Main|Association (object-oriented programming)}}[[वस्तु-उन्मुख विश्लेषण और डिजाइन]]|वस्तु-उन्मुख एनालिसिस और [[एकीकृत मॉडलिंग भाषा]] में, दो क्लासेस के बीच एक जुड़ाव क्लासेस या उनके संबंधित उदाहरणों के बीच सहयोग का प्रतिनिधित्व करता है। संघों की दिशा है; उदाहरण के लिए, दो क्लासेस के बीच एक द्वि-दिशात्मक जुड़ाव इंगित करता है कि दोनों क्लास अपने संबंधों से अवगत हैं।<ref name="ibmuml">{{cite web| url=http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/|title=UML Basics: The class diagram|last=Bell|first=Donald|work=developer Works|publisher=IBM|access-date=2012-05-02}}</ref> संघों को उनके नाम या उद्देश्य के अनुअमूर्त लेबल किया जा सकता है।{{sfn|Booch|1994|p=179}}
एक संघ की भूमिका को एक संघ का अंत दिया जाता है और संबंधित क्लास की भूमिका का वर्णन करता है। उदाहरण के लिए, एक सब्सक्राइबर भूमिका उस तरीके का वर्णन करती है जिस तरह से क्लास पर्सन क्लास मैगज़ीन के साथ सब्स्क्राइबर्स-टू एसोसिएशन में भाग लेते हैं। साथ ही, एक पत्रिका की उसी संघ में सदस्यता वाली पत्रिका की भूमिका होती है। एसोसिएशन भूमिका बहुलता बताती है कि एसोसिएशन के अन्य क्लास के प्रत्येक उदाहरण के कितने उदाहरण हैं। सामान्य गुणक 0..1 , 1..1 , 1..* और 0..* हैं, जहां * किसी भी संख्या में उदाहरणों को निर्दिष्ट करता है।<ref name=ibmuml />
एक संघ की भूमिका को एक संघ का अंत दिया जाता है और संबंधित क्लास की भूमिका का वर्णन करता है। उदाहरण के लिए, एक सब्सक्राइबर भूमिका उस तरीके का वर्णन करती है जिस तरह से क्लास पर्सन क्लास मैगज़ीन के साथ सब्स्क्राइबर्स-टू एसोसिएशन में भाग लेते हैं। साथ ही, एक पत्रिका की उसी संघ में सदस्यता वाली पत्रिका की भूमिका होती है। एसोसिएशन भूमिका बहुलता बताती है कि एसोसिएशन के अन्य क्लास के प्रत्येक उदाहरण के कितने उदाहरण हैं। सामान्य गुणक 0..1 , 1..1 , 1..* और 0..* हैं, जहां * किसी भी संख्या में उदाहरणों को निर्दिष्ट करता है।<ref name=ibmuml />




== क्लासों का क्लासीकरण ==
== क्लासेस का क्लासीकरण ==
क्लासों की कई श्रेणियां हैं, जिनमें से कुछ ओवरलैप हैं।
क्लासेस की कई श्रेणियां हैं, जिनमें से कुछ ओवरलैप हैं।


=== <स्पैन क्लास = एंकर आईडी = एब्सट्रैक्ट_एंड_कंक्रीट_क्लासेस ></span><span क्लास = एंकर आईडी = एब्सट्रेक्ट_एंड_कंक्रीट ></span> एब्सट्रैक्ट और कंक्रीट ===
=== <स्पैन क्लास = एंकर आईडी = एब्सट्रैक्ट_एंड_कंक्रीट_क्लासेस ></span><span क्लास = एंकर आईडी = एब्सट्रेक्ट_एंड_कंक्रीट ></span> एब्सट्रैक्ट और कंक्रीट ===
{{Main|Abstract type}}
{{Main|Abstract type}}
विरासत का समर्थन करने वाली भाषा में, एक अमूर्त क्लास, या अमूर्त आधार क्लास (एबीसी), एक क्लास है जिसे तत्काल नहीं किया जा सकता है क्योंकि इसे या तो अमूर्त के रूप में लेबल किया गया है या यह केवल अमूर्त विधियों (या 'वर्चुअल विधियों'') को निर्दिष्ट करता है। एक अमूर्त क्लास कुछ विधियों का कार्यान्वयन प्रदान कर सकता है, और प्रारूप के हस्ताक्षर के माध्यम से [[आभासी विधि]]यों को भी निर्दिष्ट कर सकता है जो कि अमूर्त क्लास के प्रत्यक्ष या अप्रत्यक्ष वंशजों द्वारा कार्यान्वित किया जाना है। इससे पहले कि एक अमूर्त क्लास से प्राप्त एक क्लास को तत्काल किया जा सके, उसके मूल क्लास के सभी अमूर्त तरीकों को व्युत्पत्ति श्रृंखला में कुछ क्लास द्वारा प्रयुक्त किया जाना चाहिए।<ref name="cpppoly">{{cite web|url=http://www.cplusplus.com/doc/tutorial/polymorphism/
इनहेरिटेंस का समर्थन करने वाली भाषा में, एक अमूर्त क्लास, या अमूर्त बेस क्लास (एबीसी), एक क्लास है जिसे तत्काल नहीं किया जा सकता है क्योंकि इसे या तो अमूर्त के रूप में लेबल किया गया है या यह केवल अमूर्त विधियों (या 'वर्चुअल विधियों'') को निर्दिष्ट करता है। एक अमूर्त क्लास कुछ विधियों का कार्यान्वयन प्रदान कर सकता है, और प्रारूप के हस्ताक्षर के माध्यम से [[आभासी विधि]]यों को भी निर्दिष्ट कर सकता है जो कि अमूर्त क्लास के प्रत्यक्ष या अप्रत्यक्ष वंशजों द्वारा कार्यान्वित किया जाना है। इससे पहले कि एक अमूर्त क्लास से प्राप्त एक क्लास को तत्काल किया जा सके, उसके पैरेंट क्लास के सभी अमूर्त तरीकों को व्युत्पत्ति श्रृंखला में कुछ क्लास द्वारा प्रयुक्त किया जाना चाहिए।<ref name="cpppoly">{{cite web|url=http://www.cplusplus.com/doc/tutorial/polymorphism/
|title=बहुरूपता|work=C++ Language Tutorial|publisher=cplusplus.com|access-date=2012-05-02}}</ref>''
|title=बहुरूपता|work=C++ Language Tutorial|publisher=cplusplus.com|access-date=2012-05-02}}</ref>''
अधिकांश वस्तु-उन्मुख प्रोग्रामिंग भाषा प्रोग्रामर को यह निर्दिष्ट करने की स्वीकृति देती हैं कि किन क्लासों को अमूर्त माना जाता है और इन्हें तत्काल करने की स्वीकृति नहीं दी जाएगी। उदाहरण के लिए, Java (प्रोग्रामिंग भाषा), C Sharp (प्रोग्रामिंग भाषा)|C# और [[PHP]] में, कीवर्ड एब्स्ट्रैक्ट का उपयोग किया जाता है।<ref>{{cite web| url=http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html|title=Abstract Methods and Classes|work=The Java Tutorials|publisher=Oracle|access-date=2012-05-02}}</ref><ref>{{cite web|url=http://php.net/manual/en/language.oop5.abstract.php|title=Class Abstraction|work=PHP Manual|publisher=The PHP Group|access-date=2012-05-02}}</ref> सी ++ में, एक अमूर्त क्लास एक क्लास है जिसमें कम से कम एक अमूर्त विधि है जो उस भाषा में उचित सिंटैक्स द्वारा दी गई है (सी ++ पार्लेंस में एक शुद्ध वर्चुअल फ़ंक्शन)।<ref name=cpppoly />
अधिकांश वस्तु-उन्मुख प्रोग्रामिंग भाषा प्रोग्रामर को यह निर्दिष्ट करने की स्वीकृति देती हैं कि किन क्लासेस को अमूर्त माना जाता है और इन्हें तत्काल करने की स्वीकृति नहीं दी जाएगी। उदाहरण के लिए, Java (प्रोग्रामिंग भाषा), C Sharp (प्रोग्रामिंग भाषा)|C# और [[PHP]] में, कीवर्ड एब्स्ट्रैक्ट का उपयोग किया जाता है।<ref>{{cite web| url=http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html|title=Abstract Methods and Classes|work=The Java Tutorials|publisher=Oracle|access-date=2012-05-02}}</ref><ref>{{cite web|url=http://php.net/manual/en/language.oop5.abstract.php|title=Class Abstraction|work=PHP Manual|publisher=The PHP Group|access-date=2012-05-02}}</ref> सी ++ में, एक अमूर्त क्लास एक क्लास है जिसमें कम से कम एक अमूर्त विधि है जो उस भाषा में उचित सिंटैक्स द्वारा दी गई है (सी ++ पार्लेंस में एक शुद्ध वर्चुअल फ़ंक्शन)।<ref name=cpppoly />


एक क्लास जिसमें केवल आभासी विधियाँ होती हैं, उसे C++ में शुद्ध अमूर्त आधार क्लास (या शुद्ध ABC) कहा जाता है और इसे भाषा के उपयोगकर्ताओं द्वारा इंटरफ़ेस के रूप में भी जाना जाता है।<ref name=cppinterface />अन्य भाषाएँ, विशेष रूप से जावा और सी #, भाषा में एक कीवर्ड के माध्यम से [[इंटरफ़ेस (जावा)]] नामक अमूर्त क्लासों के एक संस्करण का समर्थन करती हैं। इन भाषाओं में, [[एकाधिक वंशानुक्रम]] की स्वीकृति नहीं है, लेकिन एक क्लास कई इंटरफेस प्रयुक्त कर सकता है। ऐसी कक्षा में केवल अमूर्त अमूर्त्वजनिक रूप से सुलभ विधियां हो सकती हैं।<ref name=javainterface /><ref>{{cite web | url=http://msdn.microsoft.com/en-us/library/ms173156.aspx | title=Interfaces (C# Programming Guide) | work=C# Programming Guide | publisher=Microsoft | access-date=2013-08-15}}
एक क्लास जिसमें केवल आभासी विधियाँ होती हैं, उसे C++ में शुद्ध अमूर्त बेस क्लास (या शुद्ध ABC) कहा जाता है और इसे भाषा के उपयोगकर्ताओं द्वारा इंटरफ़ेस के रूप में भी जाना जाता है।<ref name=cppinterface />अन्य भाषाएँ, विशेष रूप से जावा और सी #, भाषा में एक कीवर्ड के माध्यम से [[इंटरफ़ेस (जावा)]] नामक अमूर्त क्लासेस के एक संस्करण का समर्थन करती हैं। इन भाषाओं में, [[एकाधिक वंशानुक्रम|एकाधिक इनहेरिटेंस]] की स्वीकृति नहीं है, लेकिन एक क्लास कई इंटरफेस प्रयुक्त कर सकता है। ऐसी क्लास में केवल अमूर्त अमूर्त्वजनिक रूप से सुलभ विधियां हो सकती हैं।<ref name=javainterface /><ref>{{cite web | url=http://msdn.microsoft.com/en-us/library/ms173156.aspx | title=Interfaces (C# Programming Guide) | work=C# Programming Guide | publisher=Microsoft | access-date=2013-08-15}}
</ref><ref>{{cite web | url=http://msdn.microsoft.com/en-us/library/ms173149.aspx | title=Inheritance (C# Programming Guide) | work=C# Programming Guide | publisher=Microsoft | access-date=2012-05-02}}
</ref><ref>{{cite web | url=http://msdn.microsoft.com/en-us/library/ms173149.aspx | title=Inheritance (C# Programming Guide) | work=C# Programming Guide | publisher=Microsoft | access-date=2012-05-02}}
</ref>
</ref>
<!--Abstract classes defined as interfaces are a much more specific usage of the more general meaning of the term ''interface'', even as used in computer science, and the concept of interfaces has seen much usage and popularity within the realm of languages that support object-orientation.-->
 
एक ठोस क्लास एक ऐसा क्लास है जो अमूर्त क्लासों के विपरीत [[तात्कालिकता (कंप्यूटर विज्ञान)]] हो सकता है, जो नहीं कर सकता।  
एक ठोस क्लास एक ऐसा क्लास है जो अमूर्त क्लासेस के विपरीत [[तात्कालिकता (कंप्यूटर विज्ञान)]] हो सकता है, जो नहीं कर सकता।  






=== स्थानीय और आंतरिक ===
=== स्थानीय और आंतरिक ===
कुछ भाषाओं में, क्लासेस को वैश्विक दायरे के अलावा [[कार्यक्षेत्र (प्रोग्रामिंग)]] में घोषित किया जा सकता है। इस तरह के कई प्रारूप के क्लास हैं।
कुछ भाषाओं में, क्लासेस को वैश्विक विस्तार के अतिरिक्त [[कार्यक्षेत्र (प्रोग्रामिंग)]] में घोषित किया जा सकता है। इस तरह के कई प्रारूप के क्लास हैं।


एक आंतरिक क्लास एक अन्य क्लास के अंदरपरिभाषित क्लास है। एक आंतरिक क्लास और उसके युक्त क्लास के बीच संबंध को दूसरे प्रारूप के क्लास संघ के रूप में भी माना जा सकता है। एक आंतरिक क्लास सामान्य रूप से न तो संलग्न क्लास के उदाहरणों से जुड़ा होता है और न ही इसके संलग्न क्लास के साथ तत्काल होता है। भाषा के आधार पर, संलग्न कक्षा के बाहर से कक्षा को संदर्भित करना संभव हो सकता है या नहीं भी हो सकता है। एक संबंधित अवधारणा ''आंतरिक प्रारूप'' है, जिसे ''आंतरिक डेटा प्रारूप'' या ''नेस्टेड प्रारूप'' के रूप में भी जाना जाता है, जो आंतरिक क्लासों की अवधारणा का एक सामान्यीकरण है। C++ एक ऐसी भाषा का उदाहरण है जो आंतरिक क्लासेस और आंतरिक प्रारूपों दोनों का समर्थन करती है ("टाइपपीफ" घोषणाओं के माध्यम से)।<ref>{{cite web | url=http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr061.htm | title=Nested classes (C++ only) | work=XL C/C++ V8.0 for AIX | publisher=IBM | access-date=2012-05-07
एक आंतरिक क्लास एक अन्य क्लास के अंदरपरिभाषित क्लास है। एक आंतरिक क्लास और उसके युक्त क्लास के बीच संबंध को दूसरे प्रारूप के क्लास संघ के रूप में भी माना जा सकता है। एक आंतरिक क्लास सामान्य रूप से न तो संलग्न क्लास के उदाहरणों से जुड़ा होता है और न ही इसके संलग्न क्लास के साथ तत्काल होता है। भाषा के आधार पर, संलग्न क्लास के बाहर से क्लास को संदर्भित करना संभव हो सकता है या नहीं भी हो सकता है। एक संबंधित अवधारणा ''आंतरिक प्रारूप'' है, जिसे ''आंतरिक डेटा प्रारूप'' या ''नेस्टेड प्रारूप'' के रूप में भी जाना जाता है, जो आंतरिक क्लासेस की अवधारणा का एक सामान्यीकरण है। C++ एक ऐसी भाषा का उदाहरण है जो आंतरिक क्लासेस और आंतरिक प्रारूपों दोनों का समर्थन करती है ("टाइपपीफ" घोषणाओं के माध्यम से)।<ref>{{cite web | url=http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr061.htm | title=Nested classes (C++ only) | work=XL C/C++ V8.0 for AIX | publisher=IBM | access-date=2012-05-07
}}</ref><ref>{{cite web | url=http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr063.htm | title=Local type names (C++ only) | work=XL C/C++ V8.0 for AIX | publisher=IBM | access-date=2012-05-07
}}</ref><ref>{{cite web | url=http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr063.htm | title=Local type names (C++ only) | work=XL C/C++ V8.0 for AIX | publisher=IBM | access-date=2012-05-07
}}
}}
</ref>
</ref>
एक अन्य प्रारूप एक स्थानीय क्लास है, जो एक प्रक्रिया या कार्य के अंदरपरिभाषित क्लास है। यह क्लास के नाम के संदर्भ को उस दायरे के अंदरसीमित करता है जहां कक्षा घोषित की जाती है। भाषा के सिमेंटिक नियमों के आधार पर, स्थानीय क्लासों पर गैर-स्थानीय लोगों की तुलना में अतिरिक्त प्रतिबंध हो सकते हैं। एक सामान्य प्रतिबंध स्थानीय क्लास विधियों को संलग्न कार्य के स्थानीय वेरीएबल तक पहुँचने के लिए अस्वीकार करना है। उदाहरण के लिए, C ++ में, एक स्थानीय क्लास अपने संलग्न कार्य के अंदरघोषित स्थिर वेरीएबल को संदर्भित कर सकता है, लेकिन फ़ंक्शन के [[स्वचालित चर|स्वचालित वेरीएबल]] तक नहीं पहुंच सकता है।<ref>{{cite web | url=http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr062.htm | title=Local classes (C++ only) | work=XL C/C++ V8.0 for AIX | publisher=IBM | access-date=2012-05-07
एक अन्य प्रारूप एक स्थानीय क्लास है, जो एक प्रक्रिया या कार्य के अंदरपरिभाषित क्लास है। यह क्लास के नाम के संदर्भ को उस विस्तार के अंदरसीमित करता है जहां क्लास घोषित की जाती है। भाषा के सिमेंटिक नियमों के आधार पर, स्थानीय क्लासेस पर गैर-स्थानीय लोगों की तुलना में अतिरिक्त प्रतिबंध हो सकते हैं। एक सामान्य प्रतिबंध स्थानीय क्लास विधियों को संलग्न कार्य के स्थानीय वेरीएबल तक अभिगम्यने के लिए अस्वीकार करना है। उदाहरण के लिए, C ++ में, एक स्थानीय क्लास अपने संलग्न कार्य के अंदरघोषित स्थिर वेरीएबल को संदर्भित कर सकता है, लेकिन फ़ंक्शन के [[स्वचालित चर|स्वचालित वेरीएबल]] तक नहीं अभिगम्य सकता है।<ref>{{cite web | url=http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr062.htm | title=Local classes (C++ only) | work=XL C/C++ V8.0 for AIX | publisher=IBM | access-date=2012-05-07
}}
}}
</ref>
</ref>
Line 157: Line 158:
</ref>
</ref>
{{sfn|Booch|1994|p=134}}
{{sfn|Booch|1994|p=134}}
[[कॉमन लिस्प ऑब्जेक्ट सिस्टम]] (सीएलओएस) उन क्लासों और मेटाक्लासेस को प्रयुक्त करने के लिए [[मेटाऑब्जेक्ट]] (एमओपी) प्रदान करता है।
[[कॉमन लिस्प ऑब्जेक्ट सिस्टम]] (सीएलओएस) उन क्लासेस और मेटाक्लासेस को प्रयुक्त करने के लिए [[मेटाऑब्जेक्ट]] (एमओपी) प्रदान करता है।
<ref>{{cite web | url=http://www.alu.org/mop/concepts.html#introduction | title=MOP: Concepts | work=The Common Lisp Object System MetaObject Protocol | publisher=Association of Lisp Users | access-date=2012-05-08 | archive-url=https://web.archive.org/web/20101115095930/http://www.alu.org/mop/concepts.html#introduction | archive-date=2010-11-15 | url-status=dead }}</ref>
<ref>{{cite web | url=http://www.alu.org/mop/concepts.html#introduction | title=MOP: Concepts | work=The Common Lisp Object System MetaObject Protocol | publisher=Association of Lisp Users | access-date=2012-05-08 | archive-url=https://web.archive.org/web/20101115095930/http://www.alu.org/mop/concepts.html#introduction | archive-date=2010-11-15 | url-status=dead }}</ref>




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


क्लास को घोषित करके एक गैर-उपक्लासीय क्लास बनाया जाता है {{code|sealed|lang=csharp}} सी # या के रूप में {{code|final|lang=java}} जावा या PHP में।<ref>{{cite web | url=http://msdn.microsoft.com/en-us/library/ms173149.aspx | title=sealed (C# Reference) | work=C# Reference | publisher=Microsoft | access-date=2012-05-08}}
क्लास को घोषित करके एक गैर-सबक्लासीय क्लास बनाया जाता है {{code|sealed|lang=csharp}} सी # या के रूप में {{code|final|lang=java}} जावा या PHP में।<ref>{{cite web | url=http://msdn.microsoft.com/en-us/library/ms173149.aspx | title=sealed (C# Reference) | work=C# Reference | publisher=Microsoft | access-date=2012-05-08}}
</ref><ref>{{cite web | url=http://docs.oracle.com/javase/tutorial/java/IandI/final.html | title=Writing Final Classes and Methods | work=The Java Tutorials | publisher=Oracle | access-date=2012-05-08}}
</ref><ref>{{cite web | url=http://docs.oracle.com/javase/tutorial/java/IandI/final.html | title=Writing Final Classes and Methods | work=The Java Tutorials | publisher=Oracle | access-date=2012-05-08}}
</ref><ref>{{cite web | url=http://php.net/manual/en/language.oop5.final.php | title=PHP: Final Keyword | work=PHP Manual | publisher=The PHP Group | access-date=2014-08-21}}
</ref><ref>{{cite web | url=http://php.net/manual/en/language.oop5.final.php | title=PHP: Final Keyword | work=PHP Manual | publisher=The PHP Group | access-date=2014-08-21}}
</ref> उदाहरण के लिए, जावा {{Java|String}} क्लास को अंतिम के रूप में नामित किया गया है।<ref>{{cite web | url=http://docs.oracle.com/javase/7/docs/api/java/lang/String.html | title=String (Java Platform SE 7) | work=Java Platform, Standard Edition 7: API Specification | publisher=Oracle | access-date=2012-05-08}}
</ref> उदाहरण के लिए, जावा {{Java|String}} क्लास को अंतिम के रूप में नामित किया गया है।<ref>{{cite web | url=http://docs.oracle.com/javase/7/docs/api/java/lang/String.html | title=String (Java Platform SE 7) | work=Java Platform, Standard Edition 7: API Specification | publisher=Oracle | access-date=2012-05-08}}
</ref>
</ref>
गैर-उपक्लासीय क्लास एक संकलक (संकलित भाषाओं में) को अनुकूलन करने की स्वीकृति दे सकते हैं जो उपक्लासीय क्लासों के लिए उपलब्ध नहीं हैं। <ref>{{cite web |last1=Brand |first1=Sy |title=The Performance Benefits of Final Classes |url=https://devblogs.microsoft.com/cppblog/the-performance-benefits-of-final-classes/ |website=Microsoft C++ team blog |date=2 March 2020 |publisher=Microsoft |access-date=4 April 2020}}</ref>
गैर-सबक्लासीय क्लास एक संकलक (संकलित भाषाओं में) को अनुकूलन करने की स्वीकृति दे सकते हैं जो सबक्लासीय क्लासेस के लिए उपलब्ध नहीं हैं। <ref>{{cite web |last1=Brand |first1=Sy |title=The Performance Benefits of Final Classes |url=https://devblogs.microsoft.com/cppblog/the-performance-benefits-of-final-classes/ |website=Microsoft C++ team blog |date=2 March 2020 |publisher=Microsoft |access-date=4 April 2020}}</ref>






=== खुली कक्षा ===
=== खुली क्लास ===
एक खुली कक्षा वह है जिसे बदला जा सकता है। सामान्य रूप से, एक निष्पादन योग्य प्रोग्राम को ग्राहकों द्वारा नहीं बदला जा सकता है। डेवलपर्स प्रायः कुछ क्लासों को बदल सकते हैं, लेकिन सामान्य रूप से मानक या बिल्ट-इन वाले नहीं बदल सकते हैं। रूबी (प्रोग्रामिंग भाषा) #ओपन क्लासेस में, सभी क्लासेस ओपन होती हैं। पायथन (प्रोग्रामिंग भाषा) में, क्लासेस रनटाइम पर बनाई जा सकती हैं, और बाद में सभी को संशोधित किया जा सकता है।<ref>{{cite web|title=9. Classes|url=https://docs.python.org/3.3/tutorial/classes.html|website=The Python Tutorial|publisher=Python.org|access-date=3 March 2018|quote=As is true for modules, classes partake of the dynamic nature of Python: they are created at runtime, and can be modified further after creation.}}</ref> ऑब्जेक्टिव-सी # कैटेगरीज | ऑब्जेक्टिव-सी श्रेणियां प्रोग्रामर को उस क्लास को फिर से कंपाइल करने या यहां तक ​​​​कि उसके सोर्स कोड तक पहुंच की आवश्यकता के बिना किसी सम्मिलिता क्लास में तरीके जोड़ने की स्वीकृति देती हैं।
एक खुली क्लास वह है जिसे बदला जा सकता है। सामान्य रूप से, एक निष्पादन योग्य प्रोग्राम को ग्राहकों द्वारा नहीं बदला जा सकता है। विकासक प्रायः कुछ क्लासेस को बदल सकते हैं, लेकिन सामान्य रूप से मानक या बिल्ट-इन वाले नहीं बदल सकते हैं। रूबी (प्रोग्रामिंग भाषा) #ओपन क्लासेस में, सभी क्लासेस ओपन होती हैं। पायथन (प्रोग्रामिंग भाषा) में, क्लासेस रनटाइम पर बनाई जा सकती हैं, और बाद में सभी को संशोधित किया जा सकता है।<ref>{{cite web|title=9. Classes|url=https://docs.python.org/3.3/tutorial/classes.html|website=The Python Tutorial|publisher=Python.org|access-date=3 March 2018|quote=As is true for modules, classes partake of the dynamic nature of Python: they are created at runtime, and can be modified further after creation.}}</ref> ऑब्जेक्टिव-सी # कैटेगरीज | ऑब्जेक्टिव-सी श्रेणियां प्रोग्रामर को उस क्लास को फिर से कंपाइल करने या यहां तक ​​​​कि उसके सोर्स कोड तक अभिगम्य की आवश्यकता के बिना किसी सम्मिलित क्लास में तरीके जोड़ने की स्वीकृति देती हैं।


=== मिश्रण ===
=== मिश्रण ===
कुछ भाषाओं में मिश्रणों के लिए विशेष समर्थन होता है, हालांकि किसी भी भाषा में एकाधिक वंशानुक्रम के साथ एक मिश्रण केवल एक क्लास है जो एक प्रारूप के संबंध का प्रतिनिधित्व नहीं करता है। [[mixin]]्स का उपयोग सामान्य रूप से एक ही तरीके को कई क्लासों में जोड़ने के लिए किया जाता है; उदाहरण के लिए, एक क्लास {{Mono|UnicodeConversionMixin}} नामक विधि प्रदान कर सकता है {{Mono|unicode_to_ascii}} जब क्लासेस में सम्मिलित किया गया {{Mono|FileReader}} और {{Mono|WebPageScraper}} जो एक सामान्य माता-पिता को साझा नहीं करते हैं।
कुछ भाषाओं में मिश्रणों के लिए विशेष समर्थन होता है, हालांकि किसी भी भाषा में एकाधिक इनहेरिटेंस के साथ एक मिश्रण केवल एक क्लास है जो एक प्रारूप के संबंध का प्रतिनिधित्व नहीं करता है। [[mixin]]्स का उपयोग सामान्य रूप से एक ही तरीके को कई क्लासेस में जोड़ने के लिए किया जाता है; उदाहरण के लिए, एक क्लास {{Mono|UnicodeConversionMixin}} नामक विधि प्रदान कर सकता है {{Mono|unicode_to_ascii}} जब क्लासेस में सम्मिलित किया गया {{Mono|FileReader}} और {{Mono|WebPageScraper}} जो एक सामान्य माता-पिता को साझा नहीं करते हैं।


=== आंशिक ===
=== आंशिक ===
{{Unreferenced section|date=April 2012}}
सुविधा का समर्थन करने वाली भाषाओं में, एक आंशिक क्लास एक ऐसा क्लास है जिसकी परिभाषा को एक ही स्रोत कोड फ़ाइल या एकाधिक फ़ाइलों में कई टुकड़ों में विभाजित किया जा सकता है।<ref name="mspartial">{{Citation|url=https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/partial-classes-and-methods|title=Partial Classes and Methods|work=C# Programming Guide|date=2015-09-19|author1=mairaw|author2=BillWagner|author3=tompratt-AQ|publisher=Microsoft|access-date=2018-08-08}}</ref> टुकड़ों को संकलन-समय पर विलय कर दिया जाता है, जिससे कंपाइलर आउटपुट एक गैर-आंशिक क्लास के समान हो जाता है।
सुविधा का समर्थन करने वाली भाषाओं में, एक आंशिक क्लास एक ऐसा क्लास है जिसकी परिभाषा को एक ही स्रोत कोड|स्रोत-कोड फ़ाइल या एकाधिक फ़ाइलों में कई टुकड़ों में विभाजित किया जा सकता है।<ref name="mspartial">{{Citation|url=https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/partial-classes-and-methods|title=Partial Classes and Methods|work=C# Programming Guide|date=2015-09-19|author1=mairaw|author2=BillWagner|author3=tompratt-AQ|publisher=Microsoft|access-date=2018-08-08}}</ref> टुकड़ों को संकलन-समय पर विलय कर दिया जाता है, जिससे कंपाइलर आउटपुट एक गैर-आंशिक क्लास के समान हो जाता है।


आंशिक क्लासेस की शुरूआत के लिए प्राथमिक प्रेरणा [[दृश्य डिजाइनर]]ों जैसे [[स्वचालित प्रोग्रामिंग]] के कार्यान्वयन की सुविधा प्रदान करना है।<ref name="mspartial"/>अन्यथा कोड उत्पन्नर विकसित करना एक चुनौती या समझौता है जो डेवलपर-लिखित कोड के अंदरइंटरलीव किए जाने पर उत्पन्न कोड को प्रबंधित कर सकता है। आंशिक क्लासेस का उपयोग करते हुए, एक कोड जनरेटर एक फ़ाइल के अंदरएक अलग फ़ाइल या मोटे अनाज वाले आंशिक क्लास को संसाधित कर सकता है, और इस प्रारूप व्यापक पार्सिंग के माध्यम से उत्पन्न कोड को जटिल रूप से इंटरजेक्ट करने से कम किया जाता है, संकलक दक्षता में वृद्धि और डेवलपर कोड को दूषित करने के संभावित जोखिम को समाप्त करता है। आंशिक क्लासेस के एक सरल कार्यान्वयन में, संकलक [[पूर्वसंकलन]] का एक वेरीएबलण कर सकता है जहां यह आंशिक क्लास के सभी भागों को एकीकृत करता है। फिर, संकलन हमेशा की तरह आगे बढ़ सकता है।
आंशिक क्लासेस की प्रारंभ के लिए प्राथमिक प्रेरणा [[दृश्य डिजाइनर]]ों जैसे [[स्वचालित प्रोग्रामिंग]] के कार्यान्वयन की सुविधा प्रदान करना है।<ref name="mspartial"/>अन्यथा कोड उत्पन्नर विकसित करना एक चुनौती या समझौता है जो विकासक-लिखित कोड के अंदर इंटरलीव किए जाने पर उत्पन्न कोड को प्रबंधित कर सकता है। आंशिक क्लासेस का उपयोग करते हुए, एक कोड जनरेटर एक फ़ाइल के अंदरएक अलग फ़ाइल या मोटे अनाज वाले आंशिक क्लास को संसाधित कर सकता है, और इस प्रारूप व्यापक पार्सिंग के माध्यम से उत्पन्न कोड को जटिल रूप से इंटरजेक्ट करने से कम किया जाता है, संकलक दक्षता में वृद्धि और विकासक कोड को दूषित करने के संभावित जोखिम को समाप्त करता है। आंशिक क्लासेस के एक सरल कार्यान्वयन में, संकलक [[पूर्वसंकलन]] का एक वेरीएबलण कर सकता है जहां यह आंशिक क्लास के सभी भागों को एकीकृत करता है। फिर, संकलन हमेशा की तरह आगे बढ़ सकता है।


आंशिक क्लास सुविधा के अन्य लाभों और प्रभावों में सम्मिलित हैं:
आंशिक क्लास सुविधा के अन्य लाभों और प्रभावों में सम्मिलित हैं:


* एक क्लास के इंटरफेस और कार्यान्वयन कोड को एक अनोखे तरीके से अलग करने में सक्षम बनाता है।
* एक क्लास के इंटरफेस और कार्यान्वयन कोड को एक अनोखे तरीके से अलग करने में सक्षम बनाता है।
* एक [[स्रोत कोड संपादक]] के अंदरबड़ी क्लासेस के माध्यम से नेविगेशन को आसान बनाता है।
* एक [[स्रोत कोड संपादक]] के अंदर बड़ी क्लासेस के माध्यम से नेविगेशन को आसान बनाता है।
* रूपरूप-उन्मुख प्रोग्रामिंग के समान, लेकिन बिना किसी अतिरिक्त टूल का उपयोग किए, चिंताओं को अलग करने में सक्षम बनाता है।
* स्वरूप-उन्मुख प्रोग्रामिंग के समान, लेकिन बिना किसी अतिरिक्त टूल का उपयोग किए, चिंताओं को अलग करने में सक्षम बनाता है।
* कई डेवलपर्स को बाद में एक फ़ाइल में अलग-अलग कोड मर्ज करने की आवश्यकता के बिना समवर्ती रूप से एक ही क्लास पर काम करने में सक्षम बनाता है।<!-- (This enabling may be considered by some or most to be a detriment rather than a benefit for SoC can apply to programmers also).-->
* कई विकासक को बाद में एक फ़ाइल में अलग-अलग कोड मर्ज करने की आवश्यकता के बिना समवर्ती रूप से एक ही क्लास पर काम करने में सक्षम बनाता है।<!-- (This enabling may be considered by some or most to be a detriment rather than a benefit for SoC can apply to programmers also).-->
स्मॉलटाक में क्लास एक्सटेंशन के नाम से आंशिक क्लासेस काफी समय से सम्मिलित हैं। .NET Framework|.NET Framework 2 के आगमन के साथ, [[Microsoft]] ने C Sharp (प्रोग्रामिंग भाषा)|C# 2.0 और Visual Basic .NET दोनों में समर्थित आंशिक क्लासेस की शुरुआत की। [[WinRT]] भी आंशिक क्लासेस का समर्थन करता है।
स्मॉलटाक में क्लास एक्सटेंशन के नाम से आंशिक क्लासेस काफी समय से सम्मिलित हैं। .NET Framework|.NET Framework 2 के आगमन के साथ, [[Microsoft]] ने C Sharp (प्रोग्रामिंग भाषा)|C# 2.0 और Visual Basic .NET दोनों में समर्थित आंशिक क्लासेस की शुरुआत की। [[WinRT]] भी आंशिक क्लासेस का समर्थन करता है।


Line 219: Line 219:


==== [[उद्देश्य सी]] में उदाहरण ====
==== [[उद्देश्य सी]] में उदाहरण ====
उद्देश्य-सी में, आंशिक क्लासेस, जिन्हें श्रेणियों के रूप में भी जाना जाता है, निम्न उदाहरणों की तरह कई पुस्तकालयों और निष्पादनयोग्य में भी फैल सकती हैं। लेकिन एक महत्वपूर्ण अंतर यह है कि ऑब्जेक्टिव-सी की श्रेणियां अन्य इंटरफ़ेस घोषणा में परिभाषाओं को अधिलेखित कर सकती हैं, और ये श्रेणियां मूल क्लास परिभाषा के बराबर नहीं हैं (पहले को अंतिम की आवश्यकता होती है)।<ref name="appleCategories">{{citation|url=https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html#//apple_ref/doc/uid/TP40011210-CH6-SW1|title=Customizing Existing Classes|work=Programming with Objective-C|date=2014-09-17|author=Apple|publisher=Apple|access-date=2018-08-08}}</ref> इसके अतिरिक्त, .NET आंशिक क्लास में परस्पर विरोधी परिभाषाएँ नहीं हो सकती हैं, और सभी आंशिक परिभाषाएँ अन्य के बराबर हैं।<ref name="mspartial"/>
उद्देश्य-सी में, आंशिक क्लासेस, जिन्हें श्रेणियों के रूप में भी जाना जाता है, निम्न उदाहरणों की तरह कई पुस्तकालयों और निष्पादन योग्य में भी विस्तार कर सकती हैं। लेकिन एक महत्वपूर्ण अंतर यह है कि ऑब्जेक्टिव-सी की श्रेणियां अन्य इंटरफ़ेस घोषणा में परिभाषाओं को अधिलेखित कर सकती हैं, और ये श्रेणियां पैरेंट क्लास परिभाषा के बराबर नहीं हैं (पहले को अंतिम की आवश्यकता होती है)।<ref name="appleCategories">{{citation|url=https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html#//apple_ref/doc/uid/TP40011210-CH6-SW1|title=Customizing Existing Classes|work=Programming with Objective-C|date=2014-09-17|author=Apple|publisher=Apple|access-date=2018-08-08}}</ref> इसके अतिरिक्त, .NET आंशिक क्लास में परस्पर विरोधी परिभाषाएँ नहीं हो सकती हैं, और सभी आंशिक परिभाषाएँ अन्य के बराबर हैं।<ref name="mspartial"/>


फाउंडेशन में, हेडर फ़ाइल NSData.h
फाउंडेशन में, हेडर फ़ाइल NSData.h
Line 267: Line 267:


== लाभ ==
== लाभ ==
सॉफ़्टवेयर को वस्तु क्लासों में व्यवस्थित करने के लाभ तीन श्रेणियों में आते हैं:<ref>{{cite web|title=What is an Object?|url=http://docs.oracle.com/javase/tutorial/java/concepts/object.html|work=oracle.com|publisher=Oracle Corporation|access-date=13 December 2013}}</ref>
सॉफ़्टवेयर को वस्तु क्लासेस में व्यवस्थित करने के लाभ तीन श्रेणियों में आते हैं:<ref>{{cite web|title=What is an Object?|url=http://docs.oracle.com/javase/tutorial/java/concepts/object.html|work=oracle.com|publisher=Oracle Corporation|access-date=13 December 2013}}</ref>
* त्वरित विकास
* त्वरित विकास
* रखरखाव में आसानी
* संरक्षण में आसानी
* कोड और डिजाइन का पुन: उपयोग
* कोड और डिजाइन का पुन: उपयोग


वस्तु क्लास तेजी से विकास की सुविधा प्रदान करते हैं क्योंकि वे कोड और उपयोगकर्ताओं के बीच शब्दार्थ अंतर को कम करते हैं। सिस्टम विश्लेषक खातों, ग्राहकों, बिलों आदि के बारे में बात करते हुए अनिवार्य रूप से समान शब्दावली का उपयोग करके डेवलपर्स और उपयोगकर्ताओं दोनों से बात कर सकते हैं। ऑब्जेक्ट क्लास प्रायः तेजी से विकास की सुविधा प्रदान करते हैं क्योंकि अधिकांश वस्तु-उन्मुख वातावरण शक्तिशाली डिबगिंग और परीक्षण टूल के साथ आते हैं। यह सत्यापित करने के लिए कि सिस्टम अपेक्षित रूप से प्रदर्शन कर रहा है, क्लासेस के उदाहरणों को रन टाइम पर निरीक्षण किया जा सकता है। इसके अलावा, कोर मेमोरी के डंप होने के अतिरिक्त, अधिकांश वस्तु-उन्मुख वातावरणों ने डिबगिंग क्षमताओं की व्याख्या की है ताकि डेवलपर ठीक से विश्लेषण कर सके कि प्रोग्राम में त्रुटि कहां हुई और यह देख सके कि कौन से तरीकों को किस तर्क और किस तर्क के साथ बुलाया गया था।<ref>{{cite book|last=Booch|first=Grady|title=Object-Oriented Analysis and Design with Applications|publisher=Addison-Wesley Professional|isbn=978-0-201-89551-3|pages=1–28|url=http://my.safaribooksonline.com/book/software-engineering-and-development/object/9780201895513|author2=Robert A. Maksimchuk |author3=Michael W. Engle |author4=Bobbi J. Young Ph.D. |author5=Jim Conallen |author6= Kelli A. Houston |access-date=20 December 2013|date=April 30, 2007|quote=There are fundamental limiting factors of human cognition; we can address these constraints through the use of decomposition, abstraction, and hierarchy.}}</ref>
वस्तु क्लास तेजी से विकास की सुविधा प्रदान करते हैं क्योंकि वे कोड और उपयोगकर्ताओं के बीच सिमैन्टिक अंतर को कम करते हैं। सिस्टम विश्लेषक खातों, ग्राहकों, बिलों आदि के बारे में बात करते हुए अनिवार्य रूप से समान शब्दावली का उपयोग करके विकासक और उपयोगकर्ताओं दोनों से बात कर सकते हैं। ऑब्जेक्ट क्लास प्रायः तेजी से विकास की सुविधा प्रदान करते हैं क्योंकि अधिकांश वस्तु-उन्मुख वातावरण शक्तिशाली डिबगिंग और परीक्षण टूल के साथ आते हैं। यह सत्यापित करने के लिए कि सिस्टम अपेक्षित रूप से प्रदर्शन कर रहा है, क्लासेस के उदाहरणों को रन टाइम पर निरीक्षण किया जा सकता है। इसके अतिरिक्त, कोर मेमोरी के डंप होने के अतिरिक्त, अधिकांश वस्तु-उन्मुख वातावरणों ने डिबगिंग क्षमताओं की व्याख्या की है ताकि विकासक ठीक से विश्लेषण कर सके कि प्रोग्राम में त्रुटि कहां हुई और यह देख सके कि कौन से तरीकों को किस तर्क और किस तर्क के साथ बुलाया गया था।<ref>{{cite book|last=Booch|first=Grady|title=Object-Oriented Analysis and Design with Applications|publisher=Addison-Wesley Professional|isbn=978-0-201-89551-3|pages=1–28|url=http://my.safaribooksonline.com/book/software-engineering-and-development/object/9780201895513|author2=Robert A. Maksimchuk |author3=Michael W. Engle |author4=Bobbi J. Young Ph.D. |author5=Jim Conallen |author6= Kelli A. Houston |access-date=20 December 2013|date=April 30, 2007|quote=There are fundamental limiting factors of human cognition; we can address these constraints through the use of decomposition, abstraction, and hierarchy.}}</ref>
ऑब्जेक्ट क्लास इनकैप्सुलेशन के माध्यम से रखरखाव में आसानी की सुविधा प्रदान करते हैं। जब डेवलपर्स को किसी वस्तु के गतिविधि को बदलने की आवश्यकता होती है, तो वे परिवर्तन को केवल उस वस्तु और उसके घटक भागों में स्थानांतरित कर सकते हैं। यह रखरखाव संवर्द्धन से अवांछित दुष्प्रभावों की संभावना को कम करता है।
 
ऑब्जेक्ट क्लास इनकैप्सुलेशन के माध्यम से संरक्षण में आसानी की सुविधा प्रदान करते हैं। जब विकासक को किसी वस्तु के गतिविधि को बदलने की आवश्यकता होती है, तो वे परिवर्तन को केवल उस वस्तु और उसके घटक भागों में स्थानांतरित कर सकते हैं। यह संरक्षण संवर्द्धन से अवांछित दुष्प्रभावों की संभावना को कम करता है।
 
सॉफ़्टवेयर का पुन: उपयोग भी ऑब्जेक्ट क्लास का उपयोग करने का एक प्रमुख लाभ है। क्लासेस इनहेरिटेंस और इंटरफेस के माध्यम से पुन: उपयोग की सुविधा प्रदान करती हैं। जब एक नए गतिविधि की आवश्यकता होती है, तो इसे प्रायः एक नया क्लास बनाकर प्राप्त किया जा सकता है और उस क्लास को उसके सुपरक्लास के डिफ़ॉल्ट गतिविधि और डेटा को इनहेरिटेंस में मिला कर गतिविधि या डेटा के कुछ स्वरूप को उसके अनुरूप बनाया जा सकता है। इंटरफेस के माध्यम से पुन: उपयोग (तरीकों के रूप में भी जाना जाता है) तब होता है जब कोई अन्य ऑब्जेक्ट किसी ऑब्जेक्ट क्लास को आमंत्रित करना चाहता है (नए प्रारूप का बनाने के अतिरिक्त)। पुन: उपयोग के लिए यह विधि कई सामान्य त्रुटियों को दूर करती है जो सॉफ़्टवेयर में अपना रास्ता बना सकती हैं जब एक प्रोग्राम दूसरे से कोड का पुन: उपयोग करता है।<ref>{{cite book|last=Jacobsen|first=Ivar|title=Object Oriented Software Engineering|year=1992|publisher=Addison-Wesley ACM Press|isbn=0-201-54435-0|author2=Magnus Christerson|author3=Patrik Jonsson|author4=Gunnar Overgaard|url=https://archive.org/details/objectorientedso00jaco}}</ref>


सॉफ़्टवेयर का पुन: उपयोग भी ऑब्जेक्ट क्लास का उपयोग करने का एक प्रमुख लाभ है। क्लासेस वंशानुक्रम और इंटरफेस के माध्यम से पुन: उपयोग की सुविधा प्रदान करती हैं। जब एक नए गतिविधि की आवश्यकता होती है, तो इसे प्रायः एक नया क्लास बनाकर प्राप्त किया जा सकता है और उस क्लास को उसके सुपरक्लास के डिफ़ॉल्ट गतिविधि और डेटा को विरासत में मिला कर गतिविधि या डेटा के कुछ रूपरूप को उसके अनुरूप बनाया जा सकता है। इंटरफेस के माध्यम से पुन: उपयोग (तरीकों के रूप में भी जाना जाता है) तब होता है जब कोई अन्य ऑब्जेक्ट किसी ऑब्जेक्ट क्लास को आमंत्रित करना चाहता है (नए प्रारूप का बनाने के अतिरिक्त)। पुन: उपयोग के लिए यह विधि कई सामान्य त्रुटियों को दूर करती है जो सॉफ़्टवेयर में अपना रास्ता बना सकती हैं जब एक प्रोग्राम दूसरे से कोड का पुन: उपयोग करता है।<ref>{{cite book|last=Jacobsen|first=Ivar|title=Object Oriented Software Engineering|year=1992|publisher=Addison-Wesley ACM Press|isbn=0-201-54435-0|author2=Magnus Christerson|author3=Patrik Jonsson|author4=Gunnar Overgaard|url=https://archive.org/details/objectorientedso00jaco}}</ref>




== रन-टाइम प्रतिनिधित्व ==
== रन-टाइम प्रतिनिधित्व ==
{{Unreferenced section|date=May 2012}}
डेटा प्रारूप के रूप में, एक क्लास को सामान्य रूप से संकलन-समय के निर्माण के रूप में माना जाता है।<ref>{{cite web |title=C++ International standard |url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf |archive-url=https://web.archive.org/web/20171209100334/http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/n4713.pdf |archive-date=2017-12-09 |url-status=live |website=Working Draft, Standard for Programming Language C++ |publisher=ISO/IEC JTC1/SC22 WG21 |access-date=5 January 2020}}</ref> एक भाषा या पुस्तकालय [[प्रोटोटाइप-आधारित प्रोग्रामिंग]] या [[फैक्टरी विधि पैटर्न]] मेटाऑब्जेक्ट्स का भी समर्थन कर सकता है जो क्लासेस के बारे में रन-टाइम जानकारी का प्रतिनिधित्व करता है, या यहां तक ​​कि मेटाडेटा का प्रतिनिधित्व करता है जो [[प्रतिबिंब (कंप्यूटर विज्ञान)]] सुविधाओं तक अभिगम्य प्रदान करता है और रन-टाइम पर डेटा संरचना स्वरूपों में कुशलतापूर्वक प्रयोग करने की क्षमता प्रदान करता है। . कई भाषाएँ क्लासेस के बारे में इस तरह की [[रन-टाइम प्रकार की जानकारी|रन-टाइम प्रारूप की जानकारी]] को एक क्लास से इस आधार पर अलग करती हैं कि रन-टाइम पर जानकारी की आवश्यकता नहीं होती है। कुछ गतिशील भाषाएँ रन-टाइम और कंपाइल-टाइम निर्माणों के बीच सख्त अंतर नहीं करती हैं, और इसलिए मेटाऑब्जेक्ट्स और क्लासेस के बीच अंतर नहीं कर सकती हैं।
डेटा प्रारूप के रूप में, एक क्लास को सामान्य रूप से संकलन-समय के निर्माण के रूप में माना जाता है।<ref>{{cite web |title=C++ International standard |url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf |archive-url=https://web.archive.org/web/20171209100334/http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/n4713.pdf |archive-date=2017-12-09 |url-status=live |website=Working Draft, Standard for Programming Language C++ |publisher=ISO/IEC JTC1/SC22 WG21 |access-date=5 January 2020}}</ref> एक भाषा या पुस्तकालय [[प्रोटोटाइप-आधारित प्रोग्रामिंग]] या [[फैक्टरी विधि पैटर्न]] मेटाऑब्जेक्ट्स का भी समर्थन कर सकता है जो क्लासेस के बारे में रन-टाइम जानकारी का प्रतिनिधित्व करता है, या यहां तक ​​कि मेटाडेटा का प्रतिनिधित्व करता है जो [[प्रतिबिंब (कंप्यूटर विज्ञान)]] सुविधाओं तक पहुंच प्रदान करता है और रन-टाइम पर डेटा संरचना स्वरूपों में हेरफेर करने की क्षमता प्रदान करता है। . कई भाषाएँ क्लासेस के बारे में इस तरह की [[रन-टाइम प्रकार की जानकारी|रन-टाइम प्रारूप की जानकारी]] को एक क्लास से इस आधार पर अलग करती हैं कि रन-टाइम पर जानकारी की आवश्यकता नहीं होती है। कुछ गतिशील भाषाएँ रन-टाइम और कंपाइल-टाइम निर्माणों के बीच सख्त अंतर नहीं करती हैं, और इसलिए मेटाऑब्जेक्ट्स और क्लासेस के बीच अंतर नहीं कर सकती हैं।


उदाहरण के लिए, यदि मानव क्लास व्यक्ति का प्रतिनिधित्व करने वाला एक मेटाऑब्जेक्ट है, तो मानव मेटाऑब्जेक्ट की सुविधाओं का उपयोग करके क्लास व्यक्ति के उदाहरण बनाए जा सकते हैं।
उदाहरण के लिए, यदि मानव क्लास व्यक्ति का प्रतिनिधित्व करने वाला एक मेटाऑब्जेक्ट है, तो मानव मेटाऑब्जेक्ट की सुविधाओं का उपयोग करके क्लास व्यक्ति के उदाहरण बनाए जा सकते हैं।
Line 286: Line 287:
== यह भी देखें ==
== यह भी देखें ==
{{Portal|Computer programming}}
{{Portal|Computer programming}}
* [[कक्षा आधारित प्रोग्रामिंग]]
* [[कक्षा आधारित प्रोग्रामिंग|क्लास आधारित प्रोग्रामिंग]]
* क्लास आरेख (यूएमएल)
* क्लास आरेख (यूएमएल)
* [[वस्तु-उन्मुख प्रोग्रामिंग भाषाओं की सूची]]
* [[वस्तु-उन्मुख प्रोग्रामिंग भाषाओं की सूची]]

Revision as of 19:10, 1 March 2023

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

जब क्लास के निर्माता द्वारा कोई ऑब्जेक्ट बनाया जाता है, तो परिणामी ऑब्जेक्ट को क्लास का एक इंस्टेंस (कंप्यूटर विज्ञान) कहा जाता है, और ऑब्जेक्ट के लिए विशिष्ट मेम्बर वेरीएबल को इंस्टेंस वेरीएबल कहा जाता है, जो क्लास में साझा किए गए क्लास वेरिएबल्स के विपरीत होता है।

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

क्लास बनाम प्रारूप

इसके सबसे आकस्मिक उपयोग में, लोग प्रायः किसी वस्तु के क्लास को संदर्भित करते हैं, लेकिन संकीर्ण रूप से बोलने वाली वस्तुओं में इंटरफ़ेस टाइप होता है, अर्थात् मेम्बर वेरीएबल के प्रारूप, मेम्बर फ़ंक्शन (विधियों) के हस्ताक्षर, और ये गुण पूर्ण करते हैं। उसी समय, एक क्लास का कार्यान्वयन (विशेष रूप से विधियों का कार्यान्वयन) होता है, और किसी दिए गए कार्यान्वयन के साथ दिए गए प्रारूप की वस्तुओं को बना सकता है।[3] प्रारूप सिद्धांत के संदर्भ में, एक क्लास एक कार्यान्वयन है‍—‌एक मूर्त डेटा संरचना और सबरूटीन्स का संग्रह‍—‌जबकि एक प्रारूप एक प्रोटोकॉल (वस्तु-उन्मुख प्रोग्रामिंग) है। विभिन्न (मूर्त) क्लास समान (अमूर्त) प्रारूप की वस्तुओं का उत्पादन कर सकते हैं (प्रारूप प्रणाली के आधार पर); उदाहरण के लिए, प्रारूप Stack दो क्लासेस के साथ प्रयुक्त किया जा सकता है – SmallStack (छोटे स्टैक के लिए तेजी से, लेकिन विकृत पैमाने पर) और ScalableStack (छोटे स्टैक के लिए अच्छी तरह से लेकिन उच्च ओवरहेड)। इसी तरह, एक क्लास में कई अलग-अलग कंस्ट्रक्टर हो सकते हैं।

क्लास प्रारूप सामान्य रूप से संज्ञाओं का प्रतिनिधित्व करते हैं, जैसे कि एक व्यक्ति, स्थान या वस्तु, या कुछ नामांकित, और एक क्लास इनके कार्यान्वयन का प्रतिनिधित्व करता है। उदाहरण के लिए, Banana प्रारूप सामान्य रूप से बनाना के गुणों और कार्यक्षमता का प्रतिनिधित्व कर सकता है, जबकि ABCBanana और XYZBanana क्लासेस बनाना के उत्पादन के तरीकों का प्रतिनिधित्व करेंगी (जैसे, बनाना के आपूर्तिकर्ता या डेटा संरचनाएं और एक वीडियो गेम में बनाना का प्रतिनिधित्व करने और आकर्षित करने के लिए फ़ंक्शन)। ABCBanana क्लास तब विशेष बनाना का उत्पादन कर सकता है: ABCBanana कए इंस्टेंस क्लास Banana प्रारूप की वस्तुएं होंगी। प्रायः एक प्रारूप का केवल एक कार्यान्वयन दिया जाता है, इस स्थिति में क्लास का नाम प्रायः प्रारूप के नाम के समान होता है।

डिजाइन और कार्यान्वयन

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

संरचना

क्लासेस के लिए एकीकृत मॉडलिंग भाषा अंकन

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

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

गतिविधि

क्लास या उसके उदाहरणों के गतिविधि को मेथड (कंप्यूटर प्रोग्रामिंग) का उपयोग करके परिभाषित किया गया है। विधियाँ सबरूटीन हैं जो वस्तुओं या क्लासेस पर काम करने की क्षमता रखती हैं। ये संचालन किसी वस्तु की स्थिति को बदल सकते हैं या इसे एक्सेस करने के तरीके प्रदान कर सकते हैं।[5] कई प्रारूप की विधियाँ सम्मिलित हैं, लेकिन उनके लिए समर्थन भाषाओं में भिन्न होता है। प्रोग्रामर कोड द्वारा कुछ प्रारूप के तरीके बनाए और कॉल किए जाते हैं, जबकि अन्य विशेष तरीके - जैसे कि कंस्ट्रक्टर, डिस्ट्रक्टर्स और रूपांतरण ऑपरेटर - कंपाइलर-उत्पन्न किए गए कोड द्वारा बनाए और कॉल किए जाते हैं। एक भाषा प्रोग्रामर को इन विशेष विधियों को परिभाषित करने और कॉल करने की स्वीकृति भी दे सकती है।[6][7]


क्लास इंटरफ़ेस की अवधारणा

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

क्लास इनहेरिटेंस का समर्थन करने वाली भाषाएँ भी क्लासेस को उन क्लासेस से इंटरफेस प्राप्त करने की स्वीकृति देती हैं जिनसे वे प्राप्त हुए हैं।

उदाहरण के लिए, यदि ''क्लास A'' ''क्लास B'' से प्राप्त होती है और यदि ''क्लास B'' इंटरफ़ेस ''इंटरफ़ेस B'' प्रयुक्त करती है तो 'क्लास A' 'इंटरफ़ेस B' द्वारा प्रदान की गई कार्यक्षमता (स्थिर और विधियों की घोषणा) को भी प्राप्त करती है।

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

वस्तु-उन्मुख प्रोग्रामिंग पद्धति निर्देश देता है कि किसी क्लास के किसी भी इंटरफ़ेस का संचालन एक दूसरे से स्वतंत्र होना है। इसका परिणाम एक स्तरित डिज़ाइन में होता है जहाँ एक इंटरफ़ेस के क्लाइंट इंटरफ़ेस में घोषित विधियों का उपयोग करते हैं। एक इंटरफ़ेस क्लाइंट के लिए किसी विशेष क्रम में एक इंटरफ़ेस के संचालन को प्रयुक्त करने की कोई आवश्यकता नहीं रखता है। इस दृष्टिकोण का लाभ यह है कि क्लाइंट कोड यह मान सकता है कि जब भी क्लाइंट के पास ऑब्जेक्ट तक अभिगम्य होती है, तो इंटरफ़ेस के संचालन उपयोग के लिए उपलब्ध होते हैं।[9][citation needed]


उदाहरण

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

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

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

सदस्य अभिगम्यता

निजी सदस्य" यहां पुनर्निर्देशित करता है। अन्य उपयोगों के लिए, निजी सदस्य क्लब और निजी सदस्य का बिल देखें।

अधिक जानकारी: जानकारी छुपाना

निम्नलिखित अभिगम्यता विनिर्देशक का एक सामान्य समूह है:[10]

  • निजी (या क्लास-निजी) क्लास तक ही अभिगम्य को प्रतिबंधित करता है। केवल वही विधियाँ जो एक ही क्लास का भाग हैं, निजी सदस्यों तक अभिगम्य कर सकती हैं।
  • संरक्षित (या क्लास-संरक्षित) क्लास को स्वयं और उसके सभी सबक्लास को सदस्य तक अभिगम्यने की स्वीकृति देता है।
  • सार्वजनिक का तात्पर्य है कि कोई भी कोड सदस्य को उसके नाम से एक्सेस कर सकता है।

हालाँकि कई वस्तु-उन्मुख भाषाएँ उपरोक्त एक्सेस विनिर्देशक का समर्थन करती हैं, उनके सिमैन्टिक भिन्न हो सकते हैं।

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

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

विभिन्न वस्तु-उन्मुख प्रोग्रामिंग भाषा सदस्य की अभिगम्य और दृश्यता को विभिन्न सीमा तक प्रयुक्त करती हैं, और भाषा के प्रारूप सिस्टम और संकलन नीतियों के आधार पर, कंपाइल-टाइम या रन टाइम पर प्रयुक्त होती हैं। उदाहरण के लिए, जावा (प्रोग्रामिंग भाषा) भाषा क्लाइंट कोड की स्वीकृति नहीं देती है जो किसी क्लास के निजी डेटा को कंपाइल करने के लिए एक्सेस करता है।[12] C ++ भाषा में, निजी तरीके दिखाई देते हैं, लेकिन इंटरफ़ेस में अभिगम्य योग्य नहीं हैं; हालाँकि, उन्हें पूरी तरह से अमूर्त क्लासेस को स्पष्ट रूप से घोषित करके अदृश्य बनाया जा सकता है जो क्लास के इंटरफेस का प्रतिनिधित्व करते हैं।[13] कुछ भाषाओं में अन्य अभिगम्य-योग्यता योजनाएँ हैं:

  • इंस्टेंस बनाम क्लास अभिगम्यता: रूबी (प्रोग्रामिंग भाषा) क्रमशः क्लास-निजी और क्लास-प्रोटेक्टेड के बदले इंस्टेंस-निजी और इंस्टेंस-संरक्षित एक्सेस विनिर्देशक का समर्थन करती है। वे इसमें भिन्न हैं कि वे उदाहरण के क्लास के अतिरिक्त उदाहरण के आधार पर ही अभिगम्य को प्रतिबंधित करते हैं।[14]
  • पक्ष समर्थक: C ++ एक तंत्र का समर्थन करता है जहां स्पष्ट रूप से क्लास के पक्ष समर्थक फ़ंक्शन के रूप में घोषित एक फ़ंक्शन निजी या संरक्षित के रूप में नामित सदस्यों तक अभिगम्य सकता है।[15]
  • पथ-आधारित: जावा एक जावा सिंटैक्स एक्सेस संशोधक के अंदर एक सदस्य तक अभिगम्य को प्रतिबंधित करने का समर्थन करता है, जो फ़ाइल का तार्किक पथ है। हालाँकि, संरक्षित सदस्यों तक अभिगम्य के लिए रूपरेखा क्लास के समान पैकेज में क्लासेस को प्रयुक्त करने के लिए जावा रूपरेखा का विस्तार करना एक सामान्य अभ्यास है। स्रोत फ़ाइल पूरी तरह से अलग स्थान पर सम्मिलित हो सकती है, और एक अलग .jar फ़ाइल में परिनियोजित की जा सकती है, फिर भी जहाँ तक जावा वर्चुअल मशीन का संबंध है, उसी तार्किक पथ में हो।[10]


अंतर-क्लास संबंध

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

रचना

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

@interface Car : NSObject

@property NSString *name;
@property Engine *engine
@property NSArray *tires;

@end

यह Car क्लास का एक इंस्टेंस NSString (एक स्ट्रिंग (कंप्यूटर विज्ञान) वस्तु), Engine, और NSArray (एक सरणी ऑब्जेक्ट) का एक उदाहरण है।

श्रेणीबद्ध

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

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

उदाहरण (आईफोन एसडीके से सरलीकृत उद्देश्य-सी 2.0 कोड):

@interface UIResponder : NSObject //...
@interface UIView : UIResponder //...
@interface UIScrollView : UIView //...
@interface UITableView : UIScrollView //...

इस उदाहरण में, एक UITableView एक UIScrollView है एक UIView एक UIResponder एक NSObject है।

सबक्लास की परिभाषाएँ

संकल्पनात्मक रूप से, एक सुपरक्लास अपने सबक्लासेस का सुपरसेट है। उदाहरण के लिए, एक सामान्य क्लास पदानुक्रम सम्मिलित होगा GraphicObject के सुपरक्लास के रूप में Rectangle और Ellipse, जबकि Square का एक सबक्लास होगा Rectangle. ये सभी समुच्चय सिद्धांत में भी उपसमुच्चय हैं, अर्थात, सभी क्लास आयत हैं लेकिन सभी आयत क्लास नहीं हैं।

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

वस्तु-उन्मुख मॉडलिंग में इस प्रारूप के संबंध सामान्य रूप से ऑब्जेक्ट गुणों के रूप में तैयार किए जाते हैं। इस उदाहरण में, Car क्लास में एक गुण होगी parts. parts वस्तुओं का एक संग्रह रखने के लिए टाइप किया जाएगा, जैसे कि उदाहरण Body, Engine, Tires, वगैरह। ऑब्जेक्ट मॉडलिंग भाषा जैसे कि यूनिफाइड मॉडलिंग भाषा में भाग और अन्य प्रारूप के संबंधों के विभिन्न पहलुओं को मॉडल करने की क्षमता सम्मिलित है - डेटा जैसे कि वस्तुओं की प्रमुखता, इनपुट और आउटपुट मूल्यों पर बाधाएं, आदि। इस जानकारी का उपयोग विकासक टूल द्वारा किया जा सकता है वस्तुओं के लिए मूल डेटा परिभाषाओं के साथ अतिरिक्त कोड उत्पन्न करें, जैसे कि म्यूटेटर विधि पर त्रुटि जाँच।[20] ऑब्जेक्ट क्लास सिस्टम को मॉडलिंग और कार्यान्वित करते समय एक महत्वपूर्ण सवाल यह है कि क्या एक क्लास में एक या एक से अधिक सुपरक्लास हो सकते हैं। वास्तविक दुनिया में वास्तविक सेट के साथ ऐसा सेट मिलना दुर्लभ होगा जो एक से अधिक अन्य सेट के साथ नहीं मिला हो। हालाँकि, जबकि कुछ प्रणालियाँ जैसे फ्लेवर और सीएलओएस एक से अधिक माता-पिता को रन टाइम पर ऐसा करने की क्षमता प्रदान करते हैं, जटिलता का परिचय देते हैं कि वस्तु-उन्मुख समुदाय में कई लोग पहली बार में ऑब्जेक्ट क्लास का उपयोग करने के लक्ष्यों के लिए विरोधाभासी मानते हैं। एक से अधिक सुपरक्लास के साथ काम करते समय यह समझना जटिल हो सकता है कि संदेश को संभालने के लिए कौन सी क्लास जिम्मेदार होगी। यदि लापरवाही से उपयोग किया जाता है तो यह सुविधा उसी प्रणाली की कुछ जटिलताओं को पेश कर सकती है और अस्पष्टता क्लासेस से बचने के लिए डिज़ाइन की गई थी।[21] अधिकांश आधुनिक वस्तु-उन्मुख भाषाओं जैसे कि स्मॉलटाक और जावा को रन टाइम पर एकल इनहेरिटेंस की आवश्यकता होती है। इन भाषाओं के लिए, एकाधिक इनहेरिटेंस मॉडलिंग के लिए उपयोगी हो सकती है लेकिन कार्यान्वयन के लिए नहीं।

हालाँकि, सेमांटिक वेब एप्लिकेशन ऑब्जेक्ट्स में कई सुपरक्लास होते हैं। इंटरनेट की अस्थिरता के लिए इस स्तर के लचीलेपन की आवश्यकता होती है और तकनीकी मानकों जैसे कि वेब ओन्टोलॉजी भाषा | वेब ओन्टोलॉजी भाषा (OWL) को इसका समर्थन करने के लिए डिज़ाइन किया गया है।

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


क्लास अवधारणा और इनहेरिटेंस की रूढ़िवादिता

हालाँकि क्लास-आधारित भाषाओं को सामान्य रूप से इनहेरिटेंस का समर्थन करने के लिए माना जाता है, इनहेरिटेंस क्लासेस की अवधारणा का एक आंतरिक स्वरूप नहीं है। कुछ भाषाएँ, जिन्हें प्रायः वस्तु-आधारित भाषाएँ कहा जाता है, क्लासेस का समर्थन करती हैं, फिर भी इनहेरिटेंस का समर्थन नहीं करती हैं। वस्तु-आधारित भाषाओं के उदाहरणों में मूल दृश्य के पुराने संस्करण सम्मिलित हैं।


वस्तु-उन्मुख विश्लेषण के भीतर

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

एक संघ की भूमिका को एक संघ का अंत दिया जाता है और संबंधित क्लास की भूमिका का वर्णन करता है। उदाहरण के लिए, एक सब्सक्राइबर भूमिका उस तरीके का वर्णन करती है जिस तरह से क्लास पर्सन क्लास मैगज़ीन के साथ सब्स्क्राइबर्स-टू एसोसिएशन में भाग लेते हैं। साथ ही, एक पत्रिका की उसी संघ में सदस्यता वाली पत्रिका की भूमिका होती है। एसोसिएशन भूमिका बहुलता बताती है कि एसोसिएशन के अन्य क्लास के प्रत्येक उदाहरण के कितने उदाहरण हैं। सामान्य गुणक 0..1 , 1..1 , 1..* और 0..* हैं, जहां * किसी भी संख्या में उदाहरणों को निर्दिष्ट करता है।[23]


क्लासेस का क्लासीकरण

क्लासेस की कई श्रेणियां हैं, जिनमें से कुछ ओवरलैप हैं।

<स्पैन क्लास = एंकर आईडी = एब्सट्रैक्ट_एंड_कंक्रीट_क्लासेस > एब्सट्रैक्ट और कंक्रीट

इनहेरिटेंस का समर्थन करने वाली भाषा में, एक अमूर्त क्लास, या अमूर्त बेस क्लास (एबीसी), एक क्लास है जिसे तत्काल नहीं किया जा सकता है क्योंकि इसे या तो अमूर्त के रूप में लेबल किया गया है या यह केवल अमूर्त विधियों (या 'वर्चुअल विधियों) को निर्दिष्ट करता है। एक अमूर्त क्लास कुछ विधियों का कार्यान्वयन प्रदान कर सकता है, और प्रारूप के हस्ताक्षर के माध्यम से आभासी विधियों को भी निर्दिष्ट कर सकता है जो कि अमूर्त क्लास के प्रत्यक्ष या अप्रत्यक्ष वंशजों द्वारा कार्यान्वित किया जाना है। इससे पहले कि एक अमूर्त क्लास से प्राप्त एक क्लास को तत्काल किया जा सके, उसके पैरेंट क्लास के सभी अमूर्त तरीकों को व्युत्पत्ति श्रृंखला में कुछ क्लास द्वारा प्रयुक्त किया जाना चाहिए।[25] अधिकांश वस्तु-उन्मुख प्रोग्रामिंग भाषा प्रोग्रामर को यह निर्दिष्ट करने की स्वीकृति देती हैं कि किन क्लासेस को अमूर्त माना जाता है और इन्हें तत्काल करने की स्वीकृति नहीं दी जाएगी। उदाहरण के लिए, Java (प्रोग्रामिंग भाषा), C Sharp (प्रोग्रामिंग भाषा)|C# और PHP में, कीवर्ड एब्स्ट्रैक्ट का उपयोग किया जाता है।[26][27] सी ++ में, एक अमूर्त क्लास एक क्लास है जिसमें कम से कम एक अमूर्त विधि है जो उस भाषा में उचित सिंटैक्स द्वारा दी गई है (सी ++ पार्लेंस में एक शुद्ध वर्चुअल फ़ंक्शन)।[25]

एक क्लास जिसमें केवल आभासी विधियाँ होती हैं, उसे C++ में शुद्ध अमूर्त बेस क्लास (या शुद्ध ABC) कहा जाता है और इसे भाषा के उपयोगकर्ताओं द्वारा इंटरफ़ेस के रूप में भी जाना जाता है।[13]अन्य भाषाएँ, विशेष रूप से जावा और सी #, भाषा में एक कीवर्ड के माध्यम से इंटरफ़ेस (जावा) नामक अमूर्त क्लासेस के एक संस्करण का समर्थन करती हैं। इन भाषाओं में, एकाधिक इनहेरिटेंस की स्वीकृति नहीं है, लेकिन एक क्लास कई इंटरफेस प्रयुक्त कर सकता है। ऐसी क्लास में केवल अमूर्त अमूर्त्वजनिक रूप से सुलभ विधियां हो सकती हैं।[19][28][29]

एक ठोस क्लास एक ऐसा क्लास है जो अमूर्त क्लासेस के विपरीत तात्कालिकता (कंप्यूटर विज्ञान) हो सकता है, जो नहीं कर सकता।


स्थानीय और आंतरिक

कुछ भाषाओं में, क्लासेस को वैश्विक विस्तार के अतिरिक्त कार्यक्षेत्र (प्रोग्रामिंग) में घोषित किया जा सकता है। इस तरह के कई प्रारूप के क्लास हैं।

एक आंतरिक क्लास एक अन्य क्लास के अंदरपरिभाषित क्लास है। एक आंतरिक क्लास और उसके युक्त क्लास के बीच संबंध को दूसरे प्रारूप के क्लास संघ के रूप में भी माना जा सकता है। एक आंतरिक क्लास सामान्य रूप से न तो संलग्न क्लास के उदाहरणों से जुड़ा होता है और न ही इसके संलग्न क्लास के साथ तत्काल होता है। भाषा के आधार पर, संलग्न क्लास के बाहर से क्लास को संदर्भित करना संभव हो सकता है या नहीं भी हो सकता है। एक संबंधित अवधारणा आंतरिक प्रारूप है, जिसे आंतरिक डेटा प्रारूप या नेस्टेड प्रारूप के रूप में भी जाना जाता है, जो आंतरिक क्लासेस की अवधारणा का एक सामान्यीकरण है। C++ एक ऐसी भाषा का उदाहरण है जो आंतरिक क्लासेस और आंतरिक प्रारूपों दोनों का समर्थन करती है ("टाइपपीफ" घोषणाओं के माध्यम से)।[30][31] एक अन्य प्रारूप एक स्थानीय क्लास है, जो एक प्रक्रिया या कार्य के अंदरपरिभाषित क्लास है। यह क्लास के नाम के संदर्भ को उस विस्तार के अंदरसीमित करता है जहां क्लास घोषित की जाती है। भाषा के सिमेंटिक नियमों के आधार पर, स्थानीय क्लासेस पर गैर-स्थानीय लोगों की तुलना में अतिरिक्त प्रतिबंध हो सकते हैं। एक सामान्य प्रतिबंध स्थानीय क्लास विधियों को संलग्न कार्य के स्थानीय वेरीएबल तक अभिगम्यने के लिए अस्वीकार करना है। उदाहरण के लिए, C ++ में, एक स्थानीय क्लास अपने संलग्न कार्य के अंदरघोषित स्थिर वेरीएबल को संदर्भित कर सकता है, लेकिन फ़ंक्शन के स्वचालित वेरीएबल तक नहीं अभिगम्य सकता है।[32]


मेटाक्लास

मेटाक्लास वे क्लास हैं जिनके उदाहरण क्लास हैं।[33] एक मेटाक्लास क्लासेस के संग्रह की एक सामान्य संरचना का वर्णन करता है और एक डिज़ाइन पैटर्न (कंप्यूटर विज्ञान) को प्रयुक्त कर सकता है या विशेष प्रारूप की क्लासेस का वर्णन कर सकता है। सॉफ्टवेयर ढांचे का वर्णन करने के लिए प्रायः मेटाक्लास का उपयोग किया जाता है।[34] कुछ भाषाओं में, जैसे कि पायथन (प्रोग्रामिंग भाषा), रूबी (प्रोग्रामिंग भाषा) या स्मॉलटाक, एक क्लास भी एक वस्तु है; इस प्रारूप प्रत्येक क्लास एक अद्वितीय मेटाक्लास का एक उदाहरण है जिसे भाषा में बनाया गया है। [4] [35] [36] कॉमन लिस्प ऑब्जेक्ट सिस्टम (सीएलओएस) उन क्लासेस और मेटाक्लासेस को प्रयुक्त करने के लिए मेटाऑब्जेक्ट (एमओपी) प्रदान करता है। [37]


गैर-सबक्लासीय

गैर-सबक्लासीय क्लासेस प्रोग्रामर को क्लासेस के क्लासेस और पदानुक्रमों को डिजाइन करने की स्वीकृति देती हैं जहां पदानुक्रम में कुछ स्तर पर, आगे की व्युत्पत्ति निषिद्ध है (एक स्वचलित क्लास को गैर-सबक्लासीय के रूप में भी नामित किया जा सकता है, किसी भी पदानुक्रम के गठन को रोकता है)। इसकी तुलना अमूर्त क्लासेस से करें, जो उपयोग करने के लिए संकेत देते हैं, प्रोत्साहित करते हैं और व्युत्पत्ति की आवश्यकता होती है। एक गैर-सबक्लासीय क्लास निहित रूप से ठोस है।

क्लास को घोषित करके एक गैर-सबक्लासीय क्लास बनाया जाता है sealed सी # या के रूप में final जावा या PHP में।[38][39][40] उदाहरण के लिए, जावा String क्लास को अंतिम के रूप में नामित किया गया है।[41] गैर-सबक्लासीय क्लास एक संकलक (संकलित भाषाओं में) को अनुकूलन करने की स्वीकृति दे सकते हैं जो सबक्लासीय क्लासेस के लिए उपलब्ध नहीं हैं। [42]


खुली क्लास

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

मिश्रण

कुछ भाषाओं में मिश्रणों के लिए विशेष समर्थन होता है, हालांकि किसी भी भाषा में एकाधिक इनहेरिटेंस के साथ एक मिश्रण केवल एक क्लास है जो एक प्रारूप के संबंध का प्रतिनिधित्व नहीं करता है। mixin्स का उपयोग सामान्य रूप से एक ही तरीके को कई क्लासेस में जोड़ने के लिए किया जाता है; उदाहरण के लिए, एक क्लास UnicodeConversionMixin नामक विधि प्रदान कर सकता है unicode_to_ascii जब क्लासेस में सम्मिलित किया गया FileReader और WebPageScraper जो एक सामान्य माता-पिता को साझा नहीं करते हैं।

आंशिक

सुविधा का समर्थन करने वाली भाषाओं में, एक आंशिक क्लास एक ऐसा क्लास है जिसकी परिभाषा को एक ही स्रोत कोड फ़ाइल या एकाधिक फ़ाइलों में कई टुकड़ों में विभाजित किया जा सकता है।[44] टुकड़ों को संकलन-समय पर विलय कर दिया जाता है, जिससे कंपाइलर आउटपुट एक गैर-आंशिक क्लास के समान हो जाता है।

आंशिक क्लासेस की प्रारंभ के लिए प्राथमिक प्रेरणा दृश्य डिजाइनरों जैसे स्वचालित प्रोग्रामिंग के कार्यान्वयन की सुविधा प्रदान करना है।[44]अन्यथा कोड उत्पन्नर विकसित करना एक चुनौती या समझौता है जो विकासक-लिखित कोड के अंदर इंटरलीव किए जाने पर उत्पन्न कोड को प्रबंधित कर सकता है। आंशिक क्लासेस का उपयोग करते हुए, एक कोड जनरेटर एक फ़ाइल के अंदरएक अलग फ़ाइल या मोटे अनाज वाले आंशिक क्लास को संसाधित कर सकता है, और इस प्रारूप व्यापक पार्सिंग के माध्यम से उत्पन्न कोड को जटिल रूप से इंटरजेक्ट करने से कम किया जाता है, संकलक दक्षता में वृद्धि और विकासक कोड को दूषित करने के संभावित जोखिम को समाप्त करता है। आंशिक क्लासेस के एक सरल कार्यान्वयन में, संकलक पूर्वसंकलन का एक वेरीएबलण कर सकता है जहां यह आंशिक क्लास के सभी भागों को एकीकृत करता है। फिर, संकलन हमेशा की तरह आगे बढ़ सकता है।

आंशिक क्लास सुविधा के अन्य लाभों और प्रभावों में सम्मिलित हैं:

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

स्मॉलटाक में क्लास एक्सटेंशन के नाम से आंशिक क्लासेस काफी समय से सम्मिलित हैं। .NET Framework|.NET Framework 2 के आगमन के साथ, Microsoft ने C Sharp (प्रोग्रामिंग भाषा)|C# 2.0 और Visual Basic .NET दोनों में समर्थित आंशिक क्लासेस की शुरुआत की। WinRT भी आंशिक क्लासेस का समर्थन करता है।

VB.NET में उदाहरण

विजुअल बेसिक .NET में लिखा गया यह सरल उदाहरण दिखाता है कि एक ही क्लास के भागों को दो अलग-अलग फाइलों में कैसे परिभाषित किया जाता है।

फ़ाइल1.वीबी:

Partial Class MyClass
    Private _name As String
End Class

फ़ाइल 2.वीबी

Partial Class MyClass
    Public Readonly Property Name() As String
         Get
             Return _name
         End Get
    End Property
End Class

संकलित होने पर, परिणाम वही होता है जैसे दो फाइलें एक के रूप में लिखी जाती हैं, जैसे:

Class MyClass
    Private _name As String
    Public Readonly Property Name() As String
         Get
             Return _name
         End Get
    End Property
End Class

उद्देश्य सी में उदाहरण

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

फाउंडेशन में, हेडर फ़ाइल NSData.h

@interface NSData : NSObject

- (id)initWithContentsOfURL:(NSURL *)URL;
//...

@end

उपयोगकर्ता द्वारा आपूर्ति की गई लाइब्रेरी में, फाउंडेशन रूपरेखा से एक अलग बाइनरी, हेडर फाइल NSData+base64.h:

#import <Foundation/Foundation.h>

@interface NSData (base64)

- (NSString *)base64String;
- (id)initWithBase64String:(NSString *)base64String;

@end

एक ऐप में, एक और अलग बाइनरी फ़ाइल, स्रोत कोड फ़ाइल main.m:

import <Foundation/Foundation.h>
import "NSData+base64.h"
int main(int argc, char *argv[]) {
   if (argc < 2)
       return EXIT_FAILURE;
   NSString *sourceURLString = [NSString stringWithCString:argv[1]];
   NSData *data = [[NSData alloc] initWithContentsOfURL:[NSURL URLWithString:sourceURLString]];
   NSLog(@"%@", [data base64String]);
   return EXIT_SUCCESS;

}


डिस्पैवेरीएबल NSData इंस्टेंस पर बुलाए गए दोनों तरीकों को ढूंढेगा और दोनों को सही तरीके से इनवॉइस करेगा।

अनइंस्टेंटेबल

अनइंस्टेंटेबल क्लासेस प्रोग्रामर्स को प्रति-क्लास क्षेत्र्स और विधियों को एक साथ समूहित करने की स्वीकृति देती हैं जो क्लास के उदाहरण के बिना रनटाइम पर एक्सेस की जा सकती हैं। वास्तव में, इस प्रारूप के क्लास के लिए इन्स्टेन्शियशन निषिद्ध है।

उदाहरण के लिए, सी # में, स्थिर चिह्नित क्लास को तत्काल नहीं किया जा सकता है, केवल स्थिर सदस्य (क्षेत्र, विधियों, अन्य) हो सकते हैं, हो सकता है कि 'इंस्टेंस कन्स्ट्रक्टर' न हो, और मुहरबंद हो। [46]


अनाम

एक अनाम क्लास या अनाम क्लास एक ऐसा क्लास है जो परिभाषा पर किसी नाम या पहचानकर्ता के लिए बाध्य नहीं है।[47][48] यह नामांकित बनाम अज्ञात फ़ंक्शन के अनुरूप है।

लाभ

सॉफ़्टवेयर को वस्तु क्लासेस में व्यवस्थित करने के लाभ तीन श्रेणियों में आते हैं:[49]

  • त्वरित विकास
  • संरक्षण में आसानी
  • कोड और डिजाइन का पुन: उपयोग

वस्तु क्लास तेजी से विकास की सुविधा प्रदान करते हैं क्योंकि वे कोड और उपयोगकर्ताओं के बीच सिमैन्टिक अंतर को कम करते हैं। सिस्टम विश्लेषक खातों, ग्राहकों, बिलों आदि के बारे में बात करते हुए अनिवार्य रूप से समान शब्दावली का उपयोग करके विकासक और उपयोगकर्ताओं दोनों से बात कर सकते हैं। ऑब्जेक्ट क्लास प्रायः तेजी से विकास की सुविधा प्रदान करते हैं क्योंकि अधिकांश वस्तु-उन्मुख वातावरण शक्तिशाली डिबगिंग और परीक्षण टूल के साथ आते हैं। यह सत्यापित करने के लिए कि सिस्टम अपेक्षित रूप से प्रदर्शन कर रहा है, क्लासेस के उदाहरणों को रन टाइम पर निरीक्षण किया जा सकता है। इसके अतिरिक्त, कोर मेमोरी के डंप होने के अतिरिक्त, अधिकांश वस्तु-उन्मुख वातावरणों ने डिबगिंग क्षमताओं की व्याख्या की है ताकि विकासक ठीक से विश्लेषण कर सके कि प्रोग्राम में त्रुटि कहां हुई और यह देख सके कि कौन से तरीकों को किस तर्क और किस तर्क के साथ बुलाया गया था।[50]

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

सॉफ़्टवेयर का पुन: उपयोग भी ऑब्जेक्ट क्लास का उपयोग करने का एक प्रमुख लाभ है। क्लासेस इनहेरिटेंस और इंटरफेस के माध्यम से पुन: उपयोग की सुविधा प्रदान करती हैं। जब एक नए गतिविधि की आवश्यकता होती है, तो इसे प्रायः एक नया क्लास बनाकर प्राप्त किया जा सकता है और उस क्लास को उसके सुपरक्लास के डिफ़ॉल्ट गतिविधि और डेटा को इनहेरिटेंस में मिला कर गतिविधि या डेटा के कुछ स्वरूप को उसके अनुरूप बनाया जा सकता है। इंटरफेस के माध्यम से पुन: उपयोग (तरीकों के रूप में भी जाना जाता है) तब होता है जब कोई अन्य ऑब्जेक्ट किसी ऑब्जेक्ट क्लास को आमंत्रित करना चाहता है (नए प्रारूप का बनाने के अतिरिक्त)। पुन: उपयोग के लिए यह विधि कई सामान्य त्रुटियों को दूर करती है जो सॉफ़्टवेयर में अपना रास्ता बना सकती हैं जब एक प्रोग्राम दूसरे से कोड का पुन: उपयोग करता है।[51]


रन-टाइम प्रतिनिधित्व

डेटा प्रारूप के रूप में, एक क्लास को सामान्य रूप से संकलन-समय के निर्माण के रूप में माना जाता है।[52] एक भाषा या पुस्तकालय प्रोटोटाइप-आधारित प्रोग्रामिंग या फैक्टरी विधि पैटर्न मेटाऑब्जेक्ट्स का भी समर्थन कर सकता है जो क्लासेस के बारे में रन-टाइम जानकारी का प्रतिनिधित्व करता है, या यहां तक ​​कि मेटाडेटा का प्रतिनिधित्व करता है जो प्रतिबिंब (कंप्यूटर विज्ञान) सुविधाओं तक अभिगम्य प्रदान करता है और रन-टाइम पर डेटा संरचना स्वरूपों में कुशलतापूर्वक प्रयोग करने की क्षमता प्रदान करता है। . कई भाषाएँ क्लासेस के बारे में इस तरह की रन-टाइम प्रारूप की जानकारी को एक क्लास से इस आधार पर अलग करती हैं कि रन-टाइम पर जानकारी की आवश्यकता नहीं होती है। कुछ गतिशील भाषाएँ रन-टाइम और कंपाइल-टाइम निर्माणों के बीच सख्त अंतर नहीं करती हैं, और इसलिए मेटाऑब्जेक्ट्स और क्लासेस के बीच अंतर नहीं कर सकती हैं।

उदाहरण के लिए, यदि मानव क्लास व्यक्ति का प्रतिनिधित्व करने वाला एक मेटाऑब्जेक्ट है, तो मानव मेटाऑब्जेक्ट की सुविधाओं का उपयोग करके क्लास व्यक्ति के उदाहरण बनाए जा सकते हैं।

यह भी देखें

टिप्पणियाँ

  1. 1.0 1.1 Gamma et al. 1995, p. 14.
  2. 2.0 2.1 Bruce 2002, 2.1 Objects, classes, and object types, https://books.google.com/books?id=9NGWq3K1RwUC&pg=PA18.
  3. Gamma et al. 1995, p. 17.
  4. 4.0 4.1 "3. Data model". The Python Language Reference. Python Software Foundation. Retrieved 2012-04-26.
  5. Booch 1994, p. 86-88.
  6. "Classes (I)". C++ Language Tutorial. cplusplus.com. Retrieved 2012-04-29.
  7. "Classes (II)". C++ Language Tutorial. cplusplus.com. Retrieved 2012-04-29.
  8. Booch 1994, p. 105.
  9. Jamrich, Parsons, June (2015-06-22). New perspectives computer concepts, 2016. Comprehensive. Boston, MA. ISBN 9781305271616. OCLC 917155105.{{cite book}}: CS1 maint: location missing publisher (link) CS1 maint: multiple names: authors list (link)
  10. 10.0 10.1 "Controlling Access to Members of a Class". The Java Tutorials. Oracle. Retrieved 2012-04-19.
  11. "OOP08-CPP. Do not return references to private data". CERT C++ Secure Coding Standard. Carnegie Mellon University. 2010-05-10. Archived from the original on 2015-10-03. Retrieved 2012-05-07.
  12. Ben-Ari, Mordechai (2007-01-24). "2.2 Identifiers" (PDF). Compile and Runtime Errors in Java. Archived (PDF) from the original on 2011-10-18. Retrieved 2012-05-07.
  13. 13.0 13.1 Wild, Fred. "C++ Interfaces". Dr. Dobb's. UBM Techweb. Retrieved 2012-05-02.
  14. Thomas; Hunt. "Classes, Objects, and Variables". Programming Ruby: The Pragmatic Programmer's Guide. Ruby-Doc.org. Retrieved 2012-04-26.
  15. "Friendship and inheritance". C++ Language Tutorial. cplusplus.com. Retrieved 2012-04-26.
  16. Booch 1994, p. 180.
  17. Booch 1994, p. 128-129.
  18. Booch 1994, p. 112.
  19. 19.0 19.1 "इंटरफेस". The Java Tutorials. Oracle. Retrieved 2012-05-01.
  20. Berfeld, Marya (2 December 2008). "UML-to-Java transformation in IBM Rational Software Architect editions and related software". IBM. Retrieved 20 December 2013.
  21. Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp. 43–69. ISBN 0-201-54435-0.
  22. Knublauch, Holger; Oberle, Daniel; Tetlow, Phil; Wallace, Evan (2006-03-09). "A Semantic Web Primer for Object-Oriented Software Developers". W3C. Retrieved 2008-07-30.
  23. 23.0 23.1 Bell, Donald. "UML Basics: The class diagram". developer Works. IBM. Retrieved 2012-05-02.
  24. Booch 1994, p. 179.
  25. 25.0 25.1 "बहुरूपता". C++ Language Tutorial. cplusplus.com. Retrieved 2012-05-02.
  26. "Abstract Methods and Classes". The Java Tutorials. Oracle. Retrieved 2012-05-02.
  27. "Class Abstraction". PHP Manual. The PHP Group. Retrieved 2012-05-02.
  28. "Interfaces (C# Programming Guide)". C# Programming Guide. Microsoft. Retrieved 2013-08-15.
  29. "Inheritance (C# Programming Guide)". C# Programming Guide. Microsoft. Retrieved 2012-05-02.
  30. "Nested classes (C++ only)". XL C/C++ V8.0 for AIX. IBM. Retrieved 2012-05-07.
  31. "Local type names (C++ only)". XL C/C++ V8.0 for AIX. IBM. Retrieved 2012-05-07.
  32. "Local classes (C++ only)". XL C/C++ V8.0 for AIX. IBM. Retrieved 2012-05-07.
  33. Booch 1994, p. 133-134.
  34. "13 Classes and metaclasses". pharo.gforge.inria.fr. Retrieved 2016-10-31.
  35. Thomas; Hunt. "Classes and Objects". Programming Ruby: The Pragmatic Programmer's Guide. Ruby-Doc.org. Retrieved 2012-05-08.
  36. Booch 1994, p. 134.
  37. "MOP: Concepts". The Common Lisp Object System MetaObject Protocol. Association of Lisp Users. Archived from the original on 2010-11-15. Retrieved 2012-05-08.
  38. "sealed (C# Reference)". C# Reference. Microsoft. Retrieved 2012-05-08.
  39. "Writing Final Classes and Methods". The Java Tutorials. Oracle. Retrieved 2012-05-08.
  40. "PHP: Final Keyword". PHP Manual. The PHP Group. Retrieved 2014-08-21.
  41. "String (Java Platform SE 7)". Java Platform, Standard Edition 7: API Specification. Oracle. Retrieved 2012-05-08.
  42. Brand, Sy (2 March 2020). "The Performance Benefits of Final Classes". Microsoft C++ team blog. Microsoft. Retrieved 4 April 2020.
  43. "9. Classes". The Python Tutorial. Python.org. Retrieved 3 March 2018. As is true for modules, classes partake of the dynamic nature of Python: they are created at runtime, and can be modified further after creation.
  44. 44.0 44.1 44.2 mairaw; BillWagner; tompratt-AQ (2015-09-19), "Partial Classes and Methods", C# Programming Guide, Microsoft, retrieved 2018-08-08
  45. Apple (2014-09-17), "Customizing Existing Classes", Programming with Objective-C, Apple, retrieved 2018-08-08
  46. "Static Classes and Static Class Members (C# Programming Guide)". C# Programming Guide. Microsoft. Retrieved 2012-05-08.
  47. "Anonymous Classes (The Java™ Tutorials > Learning the Java Language > Classes and Objects)". docs.oracle.com. Retrieved 2021-05-13.
  48. "PHP: Anonymous classes - Manual". www.php.net. Retrieved 2021-08-11.
  49. "What is an Object?". oracle.com. Oracle Corporation. Retrieved 13 December 2013.
  50. Booch, Grady; Robert A. Maksimchuk; Michael W. Engle; Bobbi J. Young Ph.D.; Jim Conallen; Kelli A. Houston (April 30, 2007). Object-Oriented Analysis and Design with Applications. Addison-Wesley Professional. pp. 1–28. ISBN 978-0-201-89551-3. Retrieved 20 December 2013. There are fundamental limiting factors of human cognition; we can address these constraints through the use of decomposition, abstraction, and hierarchy.
  51. Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. ISBN 0-201-54435-0.
  52. "C++ International standard" (PDF). Working Draft, Standard for Programming Language C++. ISO/IEC JTC1/SC22 WG21. Archived (PDF) from the original on 2017-12-09. Retrieved 5 January 2020.


संदर्भ


अग्रिम पठन