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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

रचना
क्लासेस को अन्य क्लासेस से बनाया जा सकता है, जिससे संलग्न क्लास और उसके एम्बेडेड क्लासेस के बीच एक रचनात्मक संबंध स्थापित किया जा सकता है। क्लासेस के बीच रचनात्मक संबंध को सामान्य रूप से है-a संबंध के रूप में भी जाना जाता है। उदाहरण के लिए, एक क्लास रजिस्टर संख्या के एड्रैस वाले भाग की सामग्री से बना हो सकता है और इसमें एक क्लास इंजन हो सकता है। इसलिए, एक रजिस्टर संख्या के एड्रैस वाले भाग की सामग्री में एक इंजन होता है। रचना का एक स्वरूप नियंत्रण है, जो कि उनके पास सम्मिलित उदाहरण द्वारा घटक इंस्टेंस का परिक्षेत्र है। यदि एक संलग्न वस्तु में मूल्य के अमूर्त घटक इंस्टेंस होते हैं, तो घटक और उनके संलग्न वस्तु का समय समान होता है। यदि घटक संदर्भ द्वारा समाहित हैं, तो हो सकता है कि उनका जीवनकाल समान न हो। उदाहरण के लिए, ऑब्जेक्टिव-सी 2.0 में: @interface Car : NSObject @property NSString *name; @property Engine *engine @property NSArray *tires; @end यह Car क्लास का एक इंस्टेंस NSString (एक स्ट्रिंग (कंप्यूटर विज्ञान) वस्तु), Engine, और NSArray (एक सरणी ऑब्जेक्ट) का एक उदाहरण है।

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

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

उदाहरण (आईफोन सॉफ़्टवेयर विकास किट (एसडीके) से सरलीकृत ऑब्जेक्टिव-सी 2.0 कोड): @interface UIResponder : NSObject //... @interface UIView : UIResponder //... @interface UIScrollView : UIView //... @interface UITableView : UIScrollView //... इस उदाहरण में, एक यूआईटेबलव्यू एक यूआईएसक्रोलव्यू है एक यूआईव्यू एक यूआईरेस्पोन्डर एक एनएसओब्जेक्ट है।

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

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

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

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

अधिकांश आधुनिक वस्तु-उन्मुख भाषाओं जैसे कि स्मॉलटाक और जावा को रन टाइम पर एकल इनहेरिटेंस की आवश्यकता होती है। इन भाषाओं के लिए, एकाधिक इनहेरिटेंस मॉडलिंग के लिए उपयोगी हो सकती है लेकिन कार्यान्वयन के लिए नहीं हो सकती है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कुछ भाषाओं में, जैसे कि पायथन (प्रोग्रामिंग भाषा), रूबी (प्रोग्रामिंग भाषा) या स्मॉलटाक, क्लास भी वस्तु है; इस प्रारूप प्रत्येक क्लास एक अद्वितीय मेटाक्लास का उदाहरण है जिसे भाषा में बनाया गया है।

सामान्य लिस्प ऑब्जेक्ट सिस्टम (सीएलओएस) उन क्लासेस और मेटाक्लासेस को प्रयुक्त करने के लिए मेटाऑब्जेक्ट प्रोटोकॉल (एमओपी) प्रदान करता है।

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

गैर-सबक्लासीय क्लास को sealed C # या के रूप में final जावा या हाइपरटेक्स्ट पूर्वप्रक्रमक में अंतिम घोषित करके बनाया जाता है।  उदाहरण के लिए, जावा  क्लास को अंतिम के रूप में नामित किया गया है।

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

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

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

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

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

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

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

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

फ़ाइल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

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

मूल में, हेडर फ़ाइल एनएसडेटा.एच: @interface NSData : NSObject - (id)initWithContentsOfURL:(NSURL *)URL; //... @end उपयोगकर्ता द्वारा आपूर्ति की गई लाइब्रेरी में, मूल रूपरेखा से एक अलग बाइनरी, हेडर फाइल NSData+base64.h: @interface NSData (base64) - (NSString *)base64String; - (id)initWithBase64String:(NSString *)base64String; @end एक ऐप में, एक और अलग बाइनरी फ़ाइल, स्रोत कोड फ़ाइल मुख्य.एम: import 
 * 1) import 

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; }

प्रेषक एनएसडेटा इंस्टेंस पर कॉल किए गए दोनों तरीकों को जांच करेगा और दोनों को सही तरीके से उपयोग करेगा।

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

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

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

लाभ
सॉफ़्टवेयर को वस्तु क्लासेस में व्यवस्थित करने के लाभ तीन श्रेणियों में आते हैं:
 * त्वरित विकास
 * संरक्षण में आसानी
 * कोड और डिजाइन का पुन: उपयोग

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

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

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

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

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

यह भी देखें

 * क्लास आधारित प्रोग्रामिंग
 * क्लास आरेख (यूएमएल)
 * वस्तु-उन्मुख प्रोग्रामिंग भाषाओं की सूची
 * मिक्सिन
 * वस्तु-उन्मुख प्रोग्रामिंग
 * प्रोटोटाइप आधारित प्रोग्रामिंग
 * विशेषता (कंप्यूटर प्रोग्रामिंग)

अग्रिम पठन

 * Abadi; Cardelli: A Theory of Objects
 * ISO/IEC 14882:2003 Programming Language C++, International standard
 * Class Warfare: Classes vs. Prototypes, by Brian Foote
 * Meyer, B.: "Object-oriented software construction", 2nd edition, Prentice Hall, 1997, ISBN 0-13-629155-4
 * Rumbaugh et al.: "Object-oriented modeling and design", Prentice Hall, 1991, ISBN 0-13-630054-5