ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग

वस्तु-उन्मुख प्रोग्रामिंग (ओओपी) वस्तु (ऑब्जेक्ट)" की अवधारणा पर आधारित एक प्रोग्रामिंग पैराडिग्म है, जिसमें डेटा और कोड हो सकते हैं। डेटा क्षेत्र के रूप में होता है (प्रायः विशेषता या गुण के रूप में जाना जाता है), और कोड प्रक्रियाओं के रूप में होता है (प्रायः विधियों के रूप में जाना जाता है)।

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

सबसे व्यापक रूप से उपयोग की जाने वाली प्रोग्रामिंग भाषाओं में से कई (जैसे C ++, जावा, पायथन, आदि) बहु-पैराडिग्म प्रोग्रामिंग भाषा हैं। और वे वस्तु-उन्मुख प्रोग्रामिंग को अधिक या कम सीमा के लिए सामान्य रूप से अनिवार्य, प्रक्रियात्मक प्रोग्रामिंग के संयोजन में समर्थन करते हैं।

इतिहास

किसी क्लास के लिए यूएमएल संकेतन। इस बटन क्लास में डेटा और फ़ंक्शंस के लिए वेरिएबल्स हैं। इनहेरिटेंस के माध्यम से एक सबक्लास को बटन क्लास के उपसमुच्चय के रूप में बनाया जा सकता है।ऑब्जेक्ट एक क्लास के उदाहरण हैं।

1950 के दशक के अंत और 1960 के दशक की प्रारंभ में वस्तु-उन्मुख प्रोग्रामिंग के आधुनिक अर्थों में वस्तुओं को प्रेरक करने वाली और उन्मुख शब्दावली ने मेसाचुसेट्स प्रौद्योगिक संस्थान में अपनी पहली उपस्थिति दर्ज की। कृत्रिम बुद्धि समूह के वातावरण में, 1960 की प्रारंभ में, "वस्तु" गुणों (विशेषताओं) के साथ पहचानी गई वस्तुओं (एलआईएसपी (प्रोग्रामिंग भाषा) परमाणुओं) को संदर्भित कर सकती थी;^[3]^[4] एलन केय ने बाद में 1966 में अपनी विचार पर एक शक्तिशाली प्रभाव के रूप में एलआईएसपी आंतरिक की विस्तृत समझ का उल्लेख दिया।^[5]

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

एलन के, ^[5]

एक अन्य प्रारंभिक एमआईटी उदाहरण 1960-1961 में इवान सदरलैंड द्वारा रचित स्केचपैड था; स्केचपैड के बारे में अपने शोध प्रबंध पर आधारित 1963 की तकनीकी रिपोर्ट की शब्दावली में, सदरलैंड ने "ऑब्जेक्ट" और "इंस्टेंस" ("विशेषज्ञ" या "परिभाषा" द्वारा आच्छादित की गई क्लास अवधारणा के साथ) की धारणाओं को परिभाषित किया, हालांकि यह ग्राफिकल पारस्परिक क्रिया के लिए विशेष है।^[6]इसके अतिरिक्त, एक मेसाचुसेट्स प्रौद्योगिक संस्थान एल्गोरिथम भाषा संस्करण, एईडी-0, ने डेटा संरचनाओं ("प्लेक्स", उस प्राकृत भाषा में) और प्रक्रियाओं के बीच एक सीधा लिंक स्थापित किया, जो बाद में संदेशों, विधियों और मेम्बर फंक्शन को पूर्वनिर्धारित करता है।^[7]^[8]

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

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

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

1981 में, गोल्डबर्ग ने बाइट पत्रिका के अगस्त अंक को संपादित किया, जिसमें व्यापक दर्शकों के लिए स्मॉलटाक और वस्तु-उन्मुख प्रोग्रामिंग की प्रारंभ की गई। 1986 में, कंप्यूटिंग मशीनरी के लिए संघ ने वस्तु-उन्मुख प्रोग्रामिंग, सिस्टम्स, भाषाये और एप्लिकेशन (ओओपीएसएलए) पर पहला सम्मेलन आयोजित किया, जिसमें अप्रत्याशित रूप से 1,000 लोगों ने भाग लिया। 1980 के दशक के मध्य में ब्रैड कॉक्स द्वारा ऑब्जेक्टिव-C विकसित किया गया था, जिन्होंने आईटीटी इंक में स्मॉलटाक का उपयोग किया था, और बजेर्न स्ट्रॉस्ट्रुप, जिन्होंने अपनी पीएचडी थीसिस के लिए सिमुला का उपयोग किया था, अंततः वस्तु-उन्मुख C ++ बनाने के लिए गए।^[10] 1985 में, बर्ट्रेंड मेयर ने एफिल (प्रोग्रामिंग भाषा) का पहला डिज़ाइन भी तैयार किया। सॉफ्टवेयर गुणवत्ता पर केंद्रित, एफिल विशुद्ध रूप से वस्तु-उन्मुख प्रोग्रामिंग भाषा है और संपूर्ण सॉफ्टवेयर जीवनचक्र का समर्थन करने वाला एक संकेत है। मेयर ने वस्तु-उन्मुख सॉफ्टवेयर निर्माण में सॉफ्टवेयर इंजीनियरिंग और कंप्यूटर विज्ञान से कुछ प्रमुख विचारों के आधार पर एफिल सॉफ्टवेयर विकास पद्धति का वर्णन किया। एफिल की गुणवत्ता पर ध्यान केंद्रित करने के लिए अनिवार्य है मेयर की विश्वसनीयता तंत्र, अनुबंध द्वारा डिजाइन, जो विधि और भाषा दोनों का एक अभिन्न भाग है।

टीआईओबीई इंडेक्स 2002 से 2018 तक प्रोग्रामिंग भाषा लोकप्रियता ग्राफ को मापता है। 2000 के दशक में वस्तु-उन्मुख जावा (प्रोग्रामिंग भाषा) (हरा) और और प्रक्रियात्मक प्रोग्रामिंग C (प्रोग्रामिंग भाषा) (काला) ने शीर्ष स्थान के लिए प्रतिस्पर्धा की।

1990 के दशक की प्रारंभ और मध्य में वस्तु-उन्मुख प्रोग्रामिंग प्रमुख प्रोग्रामिंग पैराडिग्म के रूप में विकसित हुई जब तकनीकों का समर्थन करने वाली प्रोग्रामिंग भाषाएं व्यापक रूप से उपलब्ध हो गईं। इनमें विजुअल फॉक्सप्रो 3.0,^[12]^[13]^[14] C ++,^[15] और डेल्फी (प्रोग्रामिंग भाषा) सम्मिलित है।^{[citation needed]} ग्राफिकल यूज़र इंटरफ़ेस की बढ़ती लोकप्रियता से इसका प्रभुत्व और बढ़ गया, जो वस्तु-उन्मुख प्रोग्रामिंग तकनीकों पर बहुत अधिक निर्भर करता है। गुप्त रूप से संबंधित गतिशील जीयूआई पुस्तकालय और वस्तु-उन्मुख प्रोग्रामिंग भाषा का एक उदाहरण मैक ओएस एक्स पर कोको रूपरेखा में पाया जा सकता है, जो ऑब्जेक्टिव-C में लिखा गया है, जो स्मॉलटाक पर आधारित सी के लिए एक ऑब्जेक्ट-ओरिएंटेड, डायनेमिक मैसेजिंग एक्सटेंशन है। वस्तु-उन्मुख प्रोग्रामिंग टूलकिट ने इवेंट-संचालित प्रोग्रामिंग की लोकप्रियता को भी बढ़ाया (हालांकि यह अवधारणा वस्तु-उन्मुख प्रोग्रामिंग तक सीमित नहीं है)।

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

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

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

विशेषताएं

वस्तु-उन्मुख प्रोग्रामिंग वस्तुओं का उपयोग करती है, लेकिन सभी संबद्ध तकनीकों और संरचनाओं को प्रत्यक्ष रूप से उन भाषाओं में समर्थित नहीं किया जाता है जो वस्तु-उन्मुख प्रोग्रामिंग का समर्थन करने का दावा करती हैं। यह ऑपरेंड पर संचालन करता है। नीचे सूचीबद्ध विशेषताएं उन भाषाओं में सामान्य हैं जिन्हें दृढ़ता से क्लास-और वस्तु-उन्मुख (या वस्तु-उन्मुख प्रोग्रामिंग समर्थन के साथ बहु- पैराडिग्म) माना जाता है, उल्लेखनीय एक्सेप्शन(आक्षेप) का उल्लेख किया गया है।^[16]^[17]^[18]^[19]

गैर-वस्तु-उन्मुख प्रोग्रामिंग भाषाओं के साथ साझा

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

मॉड्यूलर प्रोग्रामिंग समर्थन संगठनात्मक उद्देश्यों के लिए फाइलों और मॉड्यूल में समूह प्रक्रियाओं की क्षमता प्रदान करता है। मॉड्यूल नामस्थान हैं इसलिए एक मॉड्यूल में पहचानकर्ता किसी अन्य फ़ाइल या मॉड्यूल में समान नाम साझा करने वाली प्रक्रिया या वेरिएबल के साथ संघर्ष नहीं करेंगे।

ऑब्जेक्ट्स और क्लासेस

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

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

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

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

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

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

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

कुछ भाषाओं में क्लास और वस्तुओं को अन्य अवधारणाओं जैसे विशेषता (कंप्यूटर प्रोग्रामिंग) और मिक्सिन का उपयोग करके बनाया जा सकता है।

क्लास-आधारित बनाम प्रोटोटाइप-आधारित

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

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

गतिशील प्रेषण/संदेश देना

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

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

डेटा अमूर्तता

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

यदि कोई क्लास कॉलिंग कोड को आंतरिक वस्तु डेटा तक अभिगम्य की स्वीकृति नहीं देता है और केवल विधियों के माध्यम से अभिगम्य की स्वीकृति देता है, तो यह जानकारी छिपाने का एक रूप है जिसे अमूर्त (कंप्यूटर विज्ञान) के रूप में जाना जाता है। कुछ भाषाएँ (उदाहरण के लिए जावा) क्लास को स्पष्ट रूप से पहुँच प्रतिबंधों को प्रयुक्त करने देती हैं, उदाहरण के लिए private कीवर्ड के साथ आंतरिक डेटा को निरूपित करना और public कीवर्ड के साथ क्लास के बाहर कोड द्वारा उपयोग के लिए अभिप्रेत विधियों को निर्दिष्ट करना। विधियों को सार्वजनिक, निजी या मध्यवर्ती स्तरों जैसे protected (जो एक ही क्लास और उसके सबक्लास से अभिगम्य की स्वीकृति देता है, लेकिन एक अलग क्लास की वस्तुओं की स्वीकृति नहीं है) को भी डिज़ाइन किया जा सकता है। अन्य भाषाओं में (जैसे पायथन) यह केवल समागम द्वारा प्रयुक्त किया जाता है (उदाहरण के लिए, private विधियों में नाम हो सकते हैं जो बल देना से प्रारंभ होते हैं)। C #, स्विफ्ट और कोटलिन भाषाओं में, internal कीवर्ड केवल उसी असेंबली, पैकेज या मॉड्यूल में सम्मिलित फाइलों तक पहुंच की स्वीकृति देता है, जो क्लास के रूप में होती है।^[21]

कैप्सूलीकरण

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

संरचना, इनहेरिटेंस, और डेलिगेशन

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

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

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

सार क्लासेस को वस्तुओं में तत्काल नहीं किया जा सकता है; वे केवल अन्य एसओएलआईडी क्लासेस में इनहेरिटेंस के उद्देश्य से सम्मिलित हैं जिन्हें तत्काल किया जा सकता है। जावा में, किसी क्लास को सबक्लासेस होने से रोकने के लिए finalकीवर्ड का उपयोग किया जा सकता है।

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

ओपन/क्लोज़ सिद्धांत इस बात को समर्थन करता है कि क्लासेस और फंक्शन विस्तार के लिए खुले होने चाहिए, लेकिन संशोधन के लिए बंद होने चाहिए।

डेलिगेशन (वस्तु-उन्मुख प्रोग्रामिंग) एक अन्य भाषा सुविधा है जिसका उपयोग इनहेरिटेंस के विकल्प के रूप में किया जा सकता है।

बहुरूपता

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

उदाहरण के लिए, वृत्त और वर्ग प्रकार की वस्तुएँ आकार नामक एक सामान्य क्लास से ली गई हैं। प्रत्येक प्रकार के आकार के लिए ड्रा फ़ंक्शन प्रयुक्त होता है जो स्वयं को आकर्षित करने के लिए आवश्यक होता है जबकि कॉलिंग कोड किसी विशेष प्रकार के आकार को आकर्षित करने के प्रति सामान्य रह सकता है।

यह एक अन्य प्रकार का अमूर्त है जो क्लास पदानुक्रम के बाहर के कोड को सामान्य करता है और प्रयोजन के दृढ़ता से अंतर को सक्षम बनाता है।

खुला पुनरावर्तन

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

वस्तु-उन्मुख प्रोग्रामिंग भाषाएं

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

शुद्ध वस्तु-उन्मुख भाषाएँ कहलाने वाली भाषाएँ, क्योंकि उनमें सब कुछ एक वस्तु के रूप में निरंतर गतिविधि किया जाता है, मौलिक से लेकर वर्ण और विराम चिह्न तक, पूरी क्लास, प्रोटोटाइप, ब्लॉक, मॉड्यूल आदि तक तिविधि करते है। वे विशेष रूप से वस्तु-उन्मुख तरीके सुविधा के लिए डिज़ाइन किए गए थे, यहाँ तक कि प्रयुक्त करने के लिए प्रयुक्त किए गए थे। उदाहरण: रूबी (प्रोग्रामिंग भाषा), स्काला (प्रोग्रामिंग भाषा), स्मॉलटाक, एफिल (प्रोग्रामिंग भाषा), पन्ना (प्रोग्रामिंग भाषा),^[23] जेएडीए (प्रोग्रामिंग भाषा), सेल्फ (प्रोग्रामिंग भाषा), राकू (प्रोग्रामिंग भाषा)।
मुख्य रूप से वस्तु-उन्मुख प्रोग्रामिंग के लिए भाषाएँ, लेकिन कुछ प्रक्रियात्मक तत्वों के साथ डिज़ाइन की गई। उदाहरण: जावा (प्रोग्रामिंग भाषा), पायथन (प्रोग्रामिंग भाषा), C++, C# (प्रोग्रामिंग भाषा), डेल्फी (प्रोग्रामिंग भाषा)/ऑब्जेक्ट पास्कल, वीबी.नेट।
भाषाएँ जो ऐतिहासिक रूप से प्रक्रियात्मक प्रोग्रामिंग हैं, लेकिन कुछ वस्तु-उन्मुख सुविधाओं के साथ विस्तारित की गई हैं। उदाहरण: पीएचपी, पर्ल, विज़ुअल बेसिक (बेसिक से प्राप्त), एमएटीएलएबी, कोबोल 2002, फोरट्रान 2003, एबीएपी, एडीए (प्रोग्रामिंग भाषा), पास्कल (प्रोग्रामिंग भाषा)।
वस्तुओं (क्लासेस, विधियों, इनहेरिटेंस) की अधिकांश विशेषताओं वाली भाषाएँ, लेकिन एक विशिष्ट मूल रूप में है। उदाहरण: ओबेरॉन (प्रोग्रामिंग भाषा) (ओबेरॉन-1 या ओबेरॉन-2)।
अमूर्त डेटा प्रकार समर्थन वाली भाषाएँ जिनका उपयोग वस्तु-उन्मुख प्रोग्रामिंग के समान करने के लिए किया जा सकता है, लेकिन ऑब्जेक्ट-ओरिएंटेशन की सभी विशेषताओं के बिना किया जा सकता है। इसमें ऑब्जेक्ट-आधारित और प्रोटोटाइप-आधारित प्रोग्रामिंग भाषाएं सम्मिलित हैं। उदाहरण: जावास्क्रिप्ट, लुआ (प्रोग्रामिंग भाषा), मोडुला-2, सीएलयू (प्रोग्रामिंग भाषा)।
चमेलेन भाषाएँ जो वस्तु-उन्मुख सहित कई पैराडिग्म का समर्थन करती हैं। टीसीएलओओ के लिए इनमें से टीसीएल सबसे अलग है, एक हाइब्रिड ऑब्जेक्ट प्रणाली जो प्रोटोटाइप-आधारित प्रोग्रामिंग और क्लास-आधारित वस्तु-उन्मुख दोनों का समर्थन करता है।

गतिशील भाषाओं में वस्तु-उन्मुख प्रोग्रामिंग

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

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

एक नेटवर्क प्रोटोकॉल में वस्तु-उन्मुख प्रोग्रामिंग

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

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

डीडीएम का प्रारंभिक संस्करण वितरित फ़ाइल सेवाओं को परिभाषित करता है। इसे बाद में वितरित संबंधपरक डेटाबेस संरचना (डीआरडीए) की नींव के रूप में विस्तारित किया गया।

डिजाइन पैटर्न

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

इनहेरिटेंस और गतिविधि सबटाइपिंग

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

चार डिजाइन पैटर्न का समूह

डिजाइन पैटर्न (पुस्तक) | डिजाइन पैटर्न: पुन: प्रयोज्य वस्तु-उन्मुख सॉफ्टवेयर के तत्व 1994 में एरिक गामा, रिचर्ड हेल्म, राल्फ जॉनसन (कंप्यूटर वैज्ञानिक), और जॉन व्लिससाइड्स द्वारा प्रकाशित एक प्रभावशाली पुस्तक है, जिसे प्रायः विनोदपूर्वक में गैंग ऑफ़ फोर" के रूप में संदर्भित किया जाता है। वस्तु-उन्मुख प्रोग्रामिंग की क्षमताओं और नुकसान की खोज के साथ-साथ, यह 23 सामान्य प्रोग्रामिंग समस्याओं और उन्हें संशोधित करने पैटर्न का वर्णन करता है। अप्रैल 2007 तक, पुस्तक अपने 36वें मुद्रण में थी।

पुस्तक निम्नलिखित पैटर्न का वर्णन करती है:

ऑब्जेक्ट-ओरिएंटेशन और डेटाबेस

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

ऐसे वस्तु डेटाबेस भी हैं जिनका उपयोग संबंधपरक डेटाबेस प्रबंधन प्रणाली को परिवर्तित करने के लिए किया जा सकता है, लेकिन ये संबंधपरक डेटाबेस प्रबंधन प्रणाली की तरह तकनीकी और व्यावसायिक रूप से सफल नहीं रहे हैं।

वास्तविक विश्व मॉडलिंग और रिश्ते

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

हालांकि, निकलॉस विर्थ (जिन्होंने विर्थ के नियम के रूप में पहचानी जाने वाले कथन को लोकप्रिय बनाया और हार्डवेयर की तुलना में सॉफ्टवेयर तेजी से मंद हो रहा है) ने अपने पत्र में वस्तु-उन्मुख प्रोग्रामिंग के बारे में कहा, ''लुकिंग ग्लास के माध्यम से अच्छे विचार'', यह पैराडिग्म 'वास्तविक विश्व में' प्रणालियों की संरचना को ध्यान से दर्शाता है, और इसलिए यह जटिल गतिविधि के साथ मॉडल जटिल प्रणालियों के लिए उपयुक्त है^[27] (विपरीत केआईएसएस सिद्धांत)।

स्टीव येगे और अन्य ने उल्लेख किया कि प्राकृतिक भाषाओं में फंक्शन (विधियों/क्रियाओं) से पहले वस्तुओ (वस्तुओं/संज्ञाओं) को दृढ़ से प्राथमिकता देने के वस्तु-उन्मुख प्रोग्रामिंग दृष्टिकोण की कमी है।^[28] यह समस्या वस्तु-उन्मुख प्रोग्रामिंग को प्रक्रियात्मक प्रोग्रामिंग की तुलना में अधिक जटिल समाधान करने का कारण बन सकती है।^[29]

वस्तु-उन्मुख प्रोग्रामिंग और नियंत्रण संचालन

वस्तु-उन्मुख प्रोग्रामिंग को कोड के पुन: उपयोग और स्रोत कोड के सॉफ़्टवेयर संरक्षण को बढ़ाने के लिए विकसित किया गया था।^[30] नियंत्रण संचालन के पारदर्शी प्रतिनिधित्व की कोई प्राथमिकता नहीं थी और इसका तात्पर्य एक संकलक द्वारा नियंत्रित किया जाना था। समानांतर हार्डवेयर और बहुप्रचारित कोडिंग, (कंप्यूटर विज्ञान) की बढ़ती प्रासंगिकता के साथ, पारदर्शी नियंत्रण संचालन विकसित करना अधिक महत्वपूर्ण हो जाता है, वस्तु-उन्मुख प्रोग्रामिंग के साथ कुछ प्राप्त करना कठिन होता है।^[31]^[32]^[33]^[34]

उत्तरदायित्व- बनाम डेटा-संचालित डिज़ाइन

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

एसओएलआईडी और जीआरएएसपी दिशानिर्देश

एसओएलआईडी (वस्तु-उन्मुख डिज़ाइन) माइकल फेदर्स द्वारा आविष्कार किया गया एक मनेमोनिक (मेमोरी सहायक) है जो पाँच सॉफ्टवेयर इंजीनियरिंग डिज़ाइन सिद्धांतों को बताता है:

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

आलोचना

वस्तु-उन्मुख प्रोग्रामिंग पैराडिग्म की कई कारणों से आलोचना की गई है, जिसमें पुन: प्रयोज्यता और मॉड्यूलता के अपने घोषित लक्ष्यों को पूरा नहीं करना,^[35]^[36] और अन्य महत्वपूर्ण स्वरूपों (गणना/एल्गोरिदम) की कीमत पर सॉफ्टवेयर डिजाइन और मॉडलिंग (डेटा/ऑब्जेक्ट्स) के एक स्वरूप पर अधिक जोर देने के लिए सम्मिलित है।^[37]^[38]

लुका कार्डेली ने दावा किया है कि वस्तु-उन्मुख प्रोग्रामिंग कोड प्रक्रियात्मक कोड की तुलना में आंतरिक रूप से कम कुशल है, वस्तु-उन्मुख प्रोग्रामिंग को संकलित करने में अधिक समय लग सकता है, और यह कि वस्तु-उन्मुख प्रोग्रामिंग भाषाओं में क्लास विस्तार और संशोधन के संबंध में अधिकतम दोषपूर्ण मॉड्यूलता गुण हैं, और यह अधिकतम जटिल हैं।^[35] और बाद वाले बिंदु जो आर्मस्ट्रांग (प्रोग्रामिंग) द्वारा दोहराया गया है, जो एरलांग (प्रोग्रामिंग भाषा) के प्रमुख आविष्कारक हैं, जिन्हें यह कहते हुए उद्धृत किया गया है:^[36]

वस्तु-उन्मुख भाषाओं के साथ समस्या यह है कि उनके पास यह सब अंतर्निहित वातावरण है जो वे अपने साथ ले जाते हैं। आप एक केला चाहते थे लेकिन आपको जो मिला वह केला और पूरे जंगल मे सिर्फ एक गोरिल्ला पकड़े हुए था।

पोटोक एट अल द्वारा एक अध्ययन वस्तु-उन्मुख प्रोग्रामिंग और प्रक्रियात्मक दृष्टिकोण के बीच उत्पादकता में कोई महत्वपूर्ण अंतर नहीं दिखाया है।^[39]

क्रिस्टोफर जे. डेट ने कहा कि वस्तु-उन्मुख प्रोग्रामिंग की अन्य तकनीकों से महत्वपूर्ण तुलना, विशेष रूप से संबंधपरक, वस्तु-उन्मुख प्रोग्रामिंग की एक सहमत और कठोर परिभाषा की कमी के कारण कठिन है;^[40] हालाँकि, डेट और डार्वेन ने वस्तु-उन्मुख प्रोग्रामिंग पर एक सैद्धांतिक आधार प्रस्तावित किया है जो सापेक्षिक डाटाबेस प्रबंध प्रणाली का समर्थन करने के लिए वस्तु-उन्मुख प्रोग्रामिंग को एक प्रकार के अनुकूलन योग्य डेटा प्रकार के रूप में उपयोग करता है।^[41] हालांकि लेख में लॉरेंस क्रुबनेर ने दावा किया कि अन्य भाषाओं (एलआईएसपी बोलियों, कार्यात्मक भाषाओं, आदि) की तुलना में वस्तु-उन्मुख प्रोग्रामिंग भाषाओं में कोई अद्वितीय सामर्थ्य नहीं है, और अनावश्यक जटिलता का भारी भार डालती है।^[42]अलेक्जेंडर स्टेपानोव ऑब्जेक्ट ओरिएंटेशन की तुलना सामान्य प्रोग्रामिंग से प्रतिकूल रूप से करता है:^[37]

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

पॉल ग्राहम (कंप्यूटर प्रोग्रामर) ने सुझाव दिया है कि बड़ी कंपनियों के अंदर वस्तु-उन्मुख प्रोग्रामिंग की लोकप्रियता औसत प्रोग्रामर के बड़े (और प्रायः बदलते) समूहों के कारण है। ग्राहम के अनुसार, वस्तु-उन्मुख प्रोग्रामिंग द्वारा लगाया गया अनुशासन किसी एक प्रोग्रामर को बहुत अधिक नुकसान करने से रोकता है।^[43]

लियो ब्रॉडी ने वस्तुओं की स्टैंडअलोन प्रकृति और सॉफ़्टवेयर विकास के अपने आप को न दोहराने के सिद्धांत^[44] के उल्लंघन में प्रतिरूप कोड की प्रवृत्ति के बीच एक संबंध का सुझाव दिया है।^[45]

स्टीव येगे ने उल्लेख किया कि कार्यात्मक प्रोग्रामिंग के विपरीत:^[46]

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

क्लोजर के निर्माता अमीर हिक्की ने ऑब्जेक्ट प्रणाली को वास्तविक विश्व के अत्यधिक सरलीकृत मॉडल के रूप में वर्णित किया। उन्होंने समय को सही रूप से मॉडल करने में वस्तु-उन्मुख प्रोग्रामिंग की अक्षमता पर जोर दिया, जो तेजी से समस्याग्रस्त हो रहा है क्योंकि सॉफ्टवेयर प्रणाली अधिक समवर्ती हो गए हैं।^[38]

एरिक एस. रेमंड, एक यूनिक्स प्रोग्रामर और मुक्त स्रोत सॉफ्टवेयर एडवोकेट, उन दावों के आलोचक रहे हैं जो वस्तु-उन्मुख प्रोग्रामिंग को वन ट्रू सॉल्यूशन के रूप में प्रस्तुत करते हैं, और उन्होंने लिखा है कि वस्तु-उन्मुख प्रोग्रामिंग भाषा निरंतर स्तरित प्रोग्राम को प्रोत्साहित करती हैं जो पारदर्शिता को नष्ट कर देती हैं। ^[47] रेमंड इसकी तुलना यूनिक्स और C (प्रोग्रामिंग भाषा) के दृष्टिकोण से प्रतिकूल रूप से करता है।^[47]

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

इनहेरिटेंस के बारे में, रॉबर्ट सी. मार्टिन कहते हैं कि क्योंकि वे सॉफ्टवेयर हैं, संबंधित क्लास आवश्यक रूप से उन वस्तुओ के संबंधों को साझा नहीं करते हैं जिनका वे प्रतिनिधित्व करते हैं।^[51]

औपचारिक सेमेन्टिक्स

वस्तु-उन्मुख प्रणाली में ऑब्जेक्ट रन-टाइम इकाइयां हैं। वे किसी व्यक्ति, स्थान, बैंक खाते, डेटा की तालिका, या किसी भी आइटम का प्रतिनिधित्व कर सकते हैं जिसे प्रोग्राम को संभालना है।

वस्तु-उन्मुख प्रोग्रामिंग में उपयोग की जाने वाली अवधारणाओं को औपचारिक रूप देने के कई प्रयास किए गए हैं। वस्तु-उन्मुख प्रोग्रामिंग अवधारणाओं की व्याख्या के रूप में निम्नलिखित अवधारणाओं और निर्माणों का उपयोग किया गया है:

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

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

यह भी देखें

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

प्रणाली

कैड्स
सामान्य ऑब्जेक्ट अनुरोध ब्रोकर संरचना (कॉरबा)
वितरित घटक वस्तु मॉडल
वितरित डेटा प्रबंधन संरचना
जेरू

मॉडलिंग भाषाएं

आईडीईएफ4
इंटरफ़ेस विवरण भाषा
लेपस3
यूएमएल

संदर्भ

↑ Kindler, E.; Krivy, I. (2011). "Object-Oriented Simulation of systems with sophisticated control". International Journal of General Systems: 313–343. {{cite journal}}: Cite journal requires |journal= (help)
↑ Lewis, John; Loftus, William (2008). Java Software Solutions Foundations of Programming Design 6th ed. Pearson Education Inc. ISBN 978-0-321-53205-3., section 1.6 "Object-Oriented Programming"
↑ McCarthy, J.; Brayton, R.; Edwards, D.; Fox, P.; Hodes, L.; Luckham, D.; Maling, K.; Park, D.; Russell, S. (March 1969). "LISP I Programmers Manual" (PDF). Boston, Massachusetts: Artificial Intelligence Group, M.I.T. Computation Center and Research Laboratory: 88f. Archived from the original (PDF) on 17 July 2010. In the local M.I.T. patois, association lists [of atomic symbols] are also referred to as "property lists", and atomic symbols are sometimes called "objects". {{cite journal}}: Cite journal requires |journal= (help)
↑ McCarthy, John; Abrahams, Paul W.; Edwards, Daniel J.; Hart, swapnil d.; Levin, Michael I. (1962). LISP 1.5 Programmer's Manual. MIT Press. p. 105. ISBN 978-0-262-13011-0. Object — a synonym for atomic symbol
↑ ^5.0 ^5.1 "Dr. Alan Kay on the Meaning of "Object-Oriented Programming"". 2003. Retrieved 11 February 2010.
↑ Sutherland, I. E. (30 January 1963). "Sketchpad: A Man-Machine Graphical Communication System". Technical Report No. 296, Lincoln Laboratory, Massachusetts Institute of Technology via Defense Technical Information Center (stinet.dtic.mil). Archived from the original on 8 April 2013. Retrieved 17 July 2019.
↑ The Development of the Simula Languages, Kristen Nygaard, Ole-Johan Dahl, p.254 Uni-kl.ac.at
↑ Ross, Doug. "The first software engineering language". LCS/AI Lab Timeline. MIT Computer Science and Artificial Intelligence Laboratory. Retrieved 13 May 2010.
↑ ^9.0 ^9.1 Holmevik, Jan Rune (1994). "Compiling Simula: A historical study of technological genesis" (PDF). IEEE Annals of the History of Computing. 16 (4): 25–37. doi:10.1109/85.329756. S2CID 18148999. Archived from the original (PDF) on 30 August 2017. Retrieved 3 March 2018.
↑ ^10.0 ^10.1 Bertrand Meyer (2009). Touch of Class: Learning to Program Well with Objects and Contracts. Springer Science & Business Media. p. 329. Bibcode:2009tclp.book.....M. ISBN 978-3-540-92144-8.
↑ Kay, Alan. "The Early History of Smalltalk". Archived from the original on 10 July 2008. Retrieved 13 September 2007.
↑ 1995 (June) Visual FoxPro 3.0, FoxPro evolves from a procedural language to an object-oriented language. Visual FoxPro 3.0 introduces a database container, seamless client/server capabilities, support for ActiveX technologies, and OLE Automation and null support. Summary of Fox releases
↑ FoxPro History web site: Foxprohistory.org
↑ 1995 Reviewers Guide to Visual FoxPro 3.0: DFpug.de
↑ Khurana, Rohit (1 November 2009). Object Oriented Programming with C++, 1E. ISBN 978-81-259-2532-3.
↑ Deborah J. Armstrong. The Quarks of Object-Oriented Development. A survey of nearly 40 years of computing literature which identified a number of fundamental concepts found in the large majority of definitions of OOP, in descending order of popularity: Inheritance, Object, Class, Encapsulation, Method, Message Passing, Polymorphism, and Abstraction.
↑ John C. Mitchell, Concepts in programming languages, Cambridge University Press, 2003, ISBN 0-521-78098-5, p.278. Lists: Dynamic dispatch, abstraction, subtype polymorphism, and inheritance.
↑ Michael Lee Scott, Programming language pragmatics, Edition 2, Morgan Kaufmann, 2006, ISBN 0-12-633951-1, p. 470. Lists encapsulation, inheritance, and dynamic dispatch.
↑ Pierce, Benjamin (2002). Types and Programming Languages. MIT Press. ISBN 978-0-262-16209-8., section 18.1 "What is Object-Oriented Programming?" Lists: Dynamic dispatch, encapsulation or multi-methods (multiple dispatch), subtype polymorphism, inheritance or delegation, open recursion ("this"/"self")
↑ Booch, Grady (1986). Software Engineering with Ada. Addison Wesley. p. 220. ISBN 978-0-8053-0608-8. Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world.
↑ "What is Object Oriented Programming (OOP) In Simple Words? – Software Geek Bytes" (in English). 2023-01-05. Retrieved 2023-01-17.
↑ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp. 43–69. ISBN 978-0-201-54435-0.
↑ "The Emerald Programming Language". 26 February 2011.
↑ Neward, Ted (26 June 2006). "The Vietnam of Computer Science". Interoperability Happens. Archived from the original on 4 July 2006. Retrieved 2 June 2010.
↑ Meyer, Second Edition, p. 230
↑ M.Trofimov, OOOP – The Third "O" Solution: Open OOP. First Class, OMG, 1993, Vol. 3, issue 3, p.14.
↑ Wirth, Nicklaus (2006). "Good Ideas, Through the Looking Glass" (PDF). Computer. 39 (1): 28–39. doi:10.1109/mc.2006.20. S2CID 6582369. Archived from the original (PDF) on 12 October 2016. Retrieved 2 October 2016.
↑ Yegge, Steve (30 March 2006). "Execution in the Kingdom of Nouns". steve-yegge.blogspot.com. Retrieved 3 July 2010.
↑ Boronczyk, Timothy (11 June 2009). "What's Wrong with OOP". zaemis.blogspot.com. Retrieved 3 July 2010.
↑ Ambler, Scott (1 January 1998). "A Realistic Look at Object-Oriented Reuse". drdobbs.com. Retrieved 4 July 2010.
↑ Shelly, Asaf (22 August 2008). "Flaws of Object Oriented Modeling". Intel Software Network. Retrieved 4 July 2010.
↑ James, Justin (1 October 2007). "Multithreading is a verb not a noun". techrepublic.com. Archived from the original on 10 October 2007. Retrieved 4 July 2010.
↑ Shelly, Asaf (22 August 2008). "HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions". support.microsoft.com. Retrieved 4 July 2010.
↑ Robert Harper (17 April 2011). "Some thoughts on teaching FP". Existential Type Blog. Retrieved 5 December 2011.
↑ ^35.0 ^35.1 Cardelli, Luca (1996). "Bad Engineering Properties of Object-Oriented Languages". ACM Comput. Surv. 28 (4es): 150–es. doi:10.1145/242224.242415. ISSN 0360-0300. S2CID 12105785. Retrieved 21 April 2010.
↑ ^36.0 ^36.1 Armstrong, Joe. In Coders at Work: Reflections on the Craft of Programming. Peter Seibel, ed. Codersatwork.com Archived 5 March 2010 at the Wayback Machine, Accessed 13 November 2009.
↑ ^37.0 ^37.1 Stepanov, Alexander. "STLport: An Interview with A. Stepanov". Retrieved 21 April 2010.
↑ ^38.0 ^38.1 Rich Hickey, JVM Languages Summit 2009 keynote, Are We There Yet? November 2009.
↑ Potok, Thomas; Mladen Vouk; Andy Rindos (1999). "Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment" (PDF). Software: Practice and Experience. 29 (10): 833–847. doi:10.1002/(SICI)1097-024X(199908)29:10<833::AID-SPE258>3.0.CO;2-P. S2CID 57865731. Retrieved 21 April 2010.
↑ C. J. Date, Introduction to Database Systems, 6th-ed., Page 650
↑ C. J. Date, Hugh Darwen. Foundation for Future Database Systems: The Third Manifesto (2nd Edition)
↑ Krubner, Lawrence. "Object Oriented Programming is an expensive disaster which must end". smashcompany.com. Archived from the original on 14 October 2014. Retrieved 14 October 2014.
↑ Graham, Paul. "Why ARC isn't especially Object-Oriented". PaulGraham.com. Retrieved 13 November 2009.
↑ Brodie, Leo (1984). Thinking Forth (PDF). pp. 92–93. Retrieved 4 May 2018.
↑ Hunt, Andrew. "Don't Repeat Yourself". Category Extreme Programming. Retrieved 4 May 2018.
↑ "Stevey's Blog Rants: Execution in the Kingdom of Nouns". Retrieved 20 May 2020.
↑ ^47.0 ^47.1 Eric S. Raymond (2003). "The Art of Unix Programming: Unix and Object-Oriented Languages". Retrieved 6 August 2014.
↑ Pike, Rob (2 March 2004). "[9fans] Re: Threads: Sewing badges of honor onto a Kernel". comp.os.plan9 (Mailing list). Retrieved 17 November 2016.
↑ Pike, Rob (25 June 2012). "Less is exponentially more". Retrieved 1 October 2016.
↑ Pike, Rob (14 November 2012). "A few years ago I saw this page". Archived from the original on 14 August 2018. Retrieved 1 October 2016.
↑ "Uncle Bob SOLID principles". YouTube.
↑ Poll, Erik. "Subtyping and Inheritance for Categorical Datatypes" (PDF). Retrieved 5 June 2011.
↑ ^53.0 ^53.1 Abadi, Martin; Cardelli, Luca (1996). A Theory of Objects. Springer-Verlag New York, Inc. ISBN 978-0-387-94775-4. Retrieved 21 April 2010.

अग्रिम पठन

Abadi, Martin; Luca Cardelli (1998). A Theory of Objects. Springer Verlag. ISBN 978-0-387-94775-4.
Abelson, Harold; Gerald Jay Sussman (1997). Structure and Interpretation of Computer Programs. MIT Press. ISBN 978-0-262-01153-2. Archived from the original on 26 December 2017. Retrieved 22 January 2006.
Armstrong, Deborah J. (February 2006). "The Quarks of Object-Oriented Development". Communications of the ACM. 49 (2): 123–128. doi:10.1145/1113034.1113040. ISSN 0001-0782. S2CID 11485502.
Booch, Grady (1997). Object-Oriented Analysis and Design with Applications. Addison-Wesley. ISBN 978-0-8053-5340-2.
Eeles, Peter; Oliver Sims (1998). Building Business Objects. John Wiley & Sons. ISBN 978-0-471-19176-6.
Gamma, Erich; Richard Helm; Ralph Johnson; John Vlissides (1995). Design Patterns: Elements of Reusable Object Oriented Software. Addison-Wesley. Bibcode:1995dper.book.....G. ISBN 978-0-201-63361-0.
Harmon, Paul; William Morrissey (1996). The Object Technology Casebook – Lessons from Award-Winning Business Applications. John Wiley & Sons. ISBN 978-0-471-14717-6.
Jacobson, Ivar (1992). Object-Oriented Software Engineering: A Use Case-Driven Approach. Addison-Wesley. Bibcode:1992oose.book.....J. ISBN 978-0-201-54435-0.
Kay, Alan. The Early History of Smalltalk. Archived from the original on 4 April 2005. Retrieved 18 April 2005.
Meyer, Bertrand (1997). Object-Oriented Software Construction. Prentice Hall. ISBN 978-0-13-629155-8.
Pecinovsky, Rudolf (2013). OOP – Learn Object Oriented Thinking & Programming. Bruckner Publishing. ISBN 978-80-904661-8-0.
Rumbaugh, James; Michael Blaha; William Premerlani; Frederick Eddy; William Lorensen (1991). Object-Oriented Modeling and Design. Prentice Hall. ISBN 978-0-13-629841-0.
Schach, Stephen (2006). Object-Oriented and Classical Software Engineering, Seventh Edition. McGraw-Hill. ISBN 978-0-07-319126-3.
Schreiner, Axel-Tobias (1993). Object oriented programming with ANSI-C. Hanser. hdl:1850/8544. ISBN 978-3-446-17426-9.
Taylor, David A. (1992). Object-Oriented Information Systems – Planning and Implementation. John Wiley & Sons. ISBN 978-0-471-54364-0.
Weisfeld, Matt (2009). The Object-Oriented Thought Process, Third Edition. Addison-Wesley. ISBN 978-0-672-33016-2.
West, David (2004). Object Thinking (Developer Reference). Microsoft Press. ISBN 978-0-7356-1965-4.

बाहरी संबंध

[1] Kindler, E.; Krivy, I. (2011). "Object-Oriented Simulation of systems with sophisticated control". International Journal of General Systems: 313–343. {{cite journal}}: Cite journal requires |journal= (help)

[2] Lewis, John; Loftus, William (2008). Java Software Solutions Foundations of Programming Design 6th ed. Pearson Education Inc. ISBN 978-0-321-53205-3., section 1.6 "Object-Oriented Programming"

[3] McCarthy, J.; Brayton, R.; Edwards, D.; Fox, P.; Hodes, L.; Luckham, D.; Maling, K.; Park, D.; Russell, S. (March 1969). "LISP I Programmers Manual" (PDF). Boston, Massachusetts: Artificial Intelligence Group, M.I.T. Computation Center and Research Laboratory: 88f. Archived from the original (PDF) on 17 July 2010. In the local M.I.T. patois, association lists [of atomic symbols] are also referred to as "property lists", and atomic symbols are sometimes called "objects". {{cite journal}}: Cite journal requires |journal= (help)

[4] McCarthy, John; Abrahams, Paul W.; Edwards, Daniel J.; Hart, swapnil d.; Levin, Michael I. (1962). LISP 1.5 Programmer's Manual. MIT Press. p. 105. ISBN 978-0-262-13011-0. Object — a synonym for atomic symbol

[alanKayOnOO-5] 5.0 ^5.1 "Dr. Alan Kay on the Meaning of "Object-Oriented Programming"". 2003. Retrieved 11 February 2010.

[6] Sutherland, I. E. (30 January 1963). "Sketchpad: A Man-Machine Graphical Communication System". Technical Report No. 296, Lincoln Laboratory, Massachusetts Institute of Technology via Defense Technical Information Center (stinet.dtic.mil). Archived from the original on 8 April 2013. Retrieved 17 July 2019.

[simuladev-7] The Development of the Simula Languages, Kristen Nygaard, Ole-Johan Dahl, p.254 Uni-kl.ac.at

[8] Ross, Doug. "The first software engineering language". LCS/AI Lab Timeline. MIT Computer Science and Artificial Intelligence Laboratory. Retrieved 13 May 2010.

[auto-9] 9.0 ^9.1 Holmevik, Jan Rune (1994). "Compiling Simula: A historical study of technological genesis" (PDF). IEEE Annals of the History of Computing. 16 (4): 25–37. doi:10.1109/85.329756. S2CID 18148999. Archived from the original (PDF) on 30 August 2017. Retrieved 3 March 2018.

[Bertrand_Meyer_2009_329-10] 10.0 ^10.1 Bertrand Meyer (2009). Touch of Class: Learning to Program Well with Objects and Contracts. Springer Science & Business Media. p. 329. Bibcode:2009tclp.book.....M. ISBN 978-3-540-92144-8.

[st-11] Kay, Alan. "The Early History of Smalltalk". Archived from the original on 10 July 2008. Retrieved 13 September 2007.

[12] 1995 (June) Visual FoxPro 3.0, FoxPro evolves from a procedural language to an object-oriented language. Visual FoxPro 3.0 introduces a database container, seamless client/server capabilities, support for ActiveX technologies, and OLE Automation and null support. Summary of Fox releases

[13] FoxPro History web site: Foxprohistory.org

[14] 1995 Reviewers Guide to Visual FoxPro 3.0: DFpug.de

[15] Khurana, Rohit (1 November 2009). Object Oriented Programming with C++, 1E. ISBN 978-81-259-2532-3.

[ArmstrongQuarks-16] Deborah J. Armstrong. The Quarks of Object-Oriented Development. A survey of nearly 40 years of computing literature which identified a number of fundamental concepts found in the large majority of definitions of OOP, in descending order of popularity: Inheritance, Object, Class, Encapsulation, Method, Message Passing, Polymorphism, and Abstraction.

[17] John C. Mitchell, Concepts in programming languages, Cambridge University Press, 2003, ISBN 0-521-78098-5, p.278. Lists: Dynamic dispatch, abstraction, subtype polymorphism, and inheritance.

[18] Michael Lee Scott, Programming language pragmatics, Edition 2, Morgan Kaufmann, 2006, ISBN 0-12-633951-1, p. 470. Lists encapsulation, inheritance, and dynamic dispatch.

[pierce-19] Pierce, Benjamin (2002). Types and Programming Languages. MIT Press. ISBN 978-0-262-16209-8., section 18.1 "What is Object-Oriented Programming?" Lists: Dynamic dispatch, encapsulation or multi-methods (multiple dispatch), subtype polymorphism, inheritance or delegation, open recursion ("this"/"self")

[20] Booch, Grady (1986). Software Engineering with Ada. Addison Wesley. p. 220. ISBN 978-0-8053-0608-8. Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world.

[21] "What is Object Oriented Programming (OOP) In Simple Words? – Software Geek Bytes" (in English). 2023-01-05. Retrieved 2023-01-17.

[22] Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp. 43–69. ISBN 978-0-201-54435-0.

[23] "The Emerald Programming Language". 26 February 2011.

[RDMDBobjectmis-24] Neward, Ted (26 June 2006). "The Vietnam of Computer Science". Interoperability Happens. Archived from the original on 4 July 2006. Retrieved 2 June 2010.

[Meyer230-25] Meyer, Second Edition, p. 230

[26] M.Trofimov, OOOP – The Third "O" Solution: Open OOP. First Class, OMG, 1993, Vol. 3, issue 3, p.14.

[27] Wirth, Nicklaus (2006). "Good Ideas, Through the Looking Glass" (PDF). Computer. 39 (1): 28–39. doi:10.1109/mc.2006.20. S2CID 6582369. Archived from the original (PDF) on 12 October 2016. Retrieved 2 October 2016.

[executioniKoN-28] Yegge, Steve (30 March 2006). "Execution in the Kingdom of Nouns". steve-yegge.blogspot.com. Retrieved 3 July 2010.

[executioniKoN2-29] Boronczyk, Timothy (11 June 2009). "What's Wrong with OOP". zaemis.blogspot.com. Retrieved 3 July 2010.

[realisticcodereuse-30] Ambler, Scott (1 January 1998). "A Realistic Look at Object-Oriented Reuse". drdobbs.com. Retrieved 4 July 2010.

[flaws-31] Shelly, Asaf (22 August 2008). "Flaws of Object Oriented Modeling". Intel Software Network. Retrieved 4 July 2010.

[multithreadingisaverb-32] James, Justin (1 October 2007). "Multithreading is a verb not a noun". techrepublic.com. Archived from the original on 10 October 2007. Retrieved 4 July 2010.

[multicore-33] Shelly, Asaf (22 August 2008). "HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions". support.microsoft.com. Retrieved 4 July 2010.

[34] Robert Harper (17 April 2011). "Some thoughts on teaching FP". Existential Type Blog. Retrieved 5 December 2011.

[badprop-35] 35.0 ^35.1 Cardelli, Luca (1996). "Bad Engineering Properties of Object-Oriented Languages". ACM Comput. Surv. 28 (4es): 150–es. doi:10.1145/242224.242415. ISSN 0360-0300. S2CID 12105785. Retrieved 21 April 2010.

[armstrongjoe-36] 36.0 ^36.1 Armstrong, Joe. In Coders at Work: Reflections on the Craft of Programming. Peter Seibel, ed. Codersatwork.com Archived 5 March 2010 at the Wayback Machine, Accessed 13 November 2009.

[stepanov-37] 37.0 ^37.1 Stepanov, Alexander. "STLport: An Interview with A. Stepanov". Retrieved 21 April 2010.

[hickey-38] 38.0 ^38.1 Rich Hickey, JVM Languages Summit 2009 keynote, Are We There Yet? November 2009.

[39] Potok, Thomas; Mladen Vouk; Andy Rindos (1999). "Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment" (PDF). Software: Practice and Experience. 29 (10): 833–847. doi:10.1002/(SICI)1097-024X(199908)29:10<833::AID-SPE258>3.0.CO;2-P. S2CID 57865731. Retrieved 21 April 2010.

[DatePage650-40] C. J. Date, Introduction to Database Systems, 6th-ed., Page 650

[ThirdManifesto-41] C. J. Date, Hugh Darwen. Foundation for Future Database Systems: The Third Manifesto (2nd Edition)

[lawrence-42] Krubner, Lawrence. "Object Oriented Programming is an expensive disaster which must end". smashcompany.com. Archived from the original on 14 October 2014. Retrieved 14 October 2014.

[graham-43] Graham, Paul. "Why ARC isn't especially Object-Oriented". PaulGraham.com. Retrieved 13 November 2009.

[44] Brodie, Leo (1984). Thinking Forth (PDF). pp. 92–93. Retrieved 4 May 2018.

[45] Hunt, Andrew. "Don't Repeat Yourself". Category Extreme Programming. Retrieved 4 May 2018.

[yegge-46] "Stevey's Blog Rants: Execution in the Kingdom of Nouns". Retrieved 20 May 2020.

[Eric_S._Raymond_2003-47] 47.0 ^47.1 Eric S. Raymond (2003). "The Art of Unix Programming: Unix and Object-Oriented Languages". Retrieved 6 August 2014.

[48] Pike, Rob (2 March 2004). "[9fans] Re: Threads: Sewing badges of honor onto a Kernel". comp.os.plan9 (Mailing list). Retrieved 17 November 2016.

[49] Pike, Rob (25 June 2012). "Less is exponentially more". Retrieved 1 October 2016.

[50] Pike, Rob (14 November 2012). "A few years ago I saw this page". Archived from the original on 14 August 2018. Retrieved 1 October 2016.

[51] "Uncle Bob SOLID principles". YouTube.

[poll97-52] Poll, Erik. "Subtyping and Inheritance for Categorical Datatypes" (PDF). Retrieved 5 June 2011.

[AbadiCardelli-53] 53.0 ^53.1 Abadi, Martin; Cardelli, Luca (1996). A Theory of Objects. Springer-Verlag New York, Inc. ISBN 978-0-387-94775-4. Retrieved 21 April 2010.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

Anonymous

Search