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

From Vigyanwiki
Revision as of 19:55, 19 February 2023 by alpha>Radhamishra

"वस्तु-उन्मुख" यहां पुनर्निर्देश करता है। वस्तु-उन्मुख के अन्य अर्थों के लिए, वस्तु-उन्मुखीकरण देखें।

Programming paradigms

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

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

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

महत्वपूर्ण वस्तु-उन्मुख भाषाओं में एडीए (प्रोग्रामिंग भाषा), ActionScript, C++, सामान्य लिस्प, C #, डार्ट (प्रोग्रामिंग भाषा), एफिल (प्रोग्रामिंग भाषा), फोरट्रान 2003, हैक्स, जावा (प्रोग्रामिंग भाषा) , जावास्क्रिप्ट, कोटलिन (प्रोग्रामिंग भाषा), लोगो (प्रोग्रामिंग भाषा), मैटलैब, ऑब्जेक्टिव-C, ऑब्जेक्ट पास्कल, पर्ल, पीएचपी, पायथन (प्रोग्रामिंग भाषा), आर (प्रोग्रामिंग भाषा), राकू (प्रोग्रामिंग भाषा), रूबी (प्रोग्रामिंग भाषा) ), स्काला (प्रोग्रामिंग भाषा), सिमस्क्रिप्ट, सिमुला, स्मॉलटॉक, स्विफ्ट (प्रोग्रामिंग भाषा), वाला (प्रोग्रामिंग भाषा) और विजुअल बेसिक.नेट सम्मिलित हैं।

इतिहास

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

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

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

एलन के, [5]

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

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

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

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

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

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

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

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

विशेषताएं

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

See also: Comparison of programming languages (object-oriented programming) and List of object-oriented programming terms


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

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

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

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

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

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

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

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

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

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

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

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

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

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

डायनेमिक डिस्पैच/संदेश देना

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

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

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

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

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


एनकैप्सुलेशन

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

संरचना, विरासत, और प्रतिनिधिमंडल

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

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

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

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

खुला/बंद सिद्धांत इस बात की वकालत करता है कि कक्षाएं और कार्य विस्तार के लिए खुले होने चाहिए, लेकिन संशोधन के लिए बंद होने चाहिए।

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

बहुरूपता

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

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

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

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

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

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

See also: List of object-oriented programming languages

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

  • शुद्ध वस्तु-उन्मुख भाषाएँ कहलाने वाली भाषाएँ, क्योंकि उनमें सब कुछ एक वस्तु के रूप में लगातार गतिविधि किया जाता है, आदिम से लेकर वर्ण और विराम चिह्न तक, सभी तरह से पूरी क्लास, प्रोटोटाइप, ब्लॉक, मॉड्यूल आदि तक। वे विशेष रूप से सुविधा के लिए डिज़ाइन किए गए थे, यहाँ तक कि लागू करें, वस्तु-उन्मुख तरीके। उदाहरण: रूबी (प्रोग्रामिंग भाषा), स्काला (प्रोग्रामिंग भाषा), स्मॉलटाक, एफिल (प्रोग्रामिंग भाषा), पन्ना (प्रोग्रामिंग भाषा),[23] JADE (प्रोग्रामिंग भाषा), स्वयं (प्रोग्रामिंग भाषा), राकू (प्रोग्रामिंग भाषा)।
  • मुख्य रूप से वस्तु-उन्मुख प्रोग्रामिंग के लिए डिज़ाइन की गई भाषाएँ, लेकिन कुछ प्रक्रियात्मक तत्वों के साथ। उदाहरण: जावा (प्रोग्रामिंग भाषा), पायथन (प्रोग्रामिंग भाषा), सी++, सी शार्प (प्रोग्रामिंग भाषा)|सी#, डेल्फी (प्रोग्रामिंग भाषा)/ऑब्जेक्ट पास्कल, वीबी.नेट।
  • भाषाएँ जो ऐतिहासिक रूप से प्रक्रियात्मक प्रोग्रामिंग हैं, लेकिन कुछ वस्तु-उन्मुख सुविधाओं के साथ विस्तारित की गई हैं। उदाहरण: PHP, पर्ल, मूल दृश्य (बेसिक से प्राप्त), MATLAB, COBOL 2002, फोरट्रान 2003, ABAP, Ada (प्रोग्रामिंग भाषा), पास्कल (प्रोग्रामिंग भाषा)।
  • वस्तुओं (वर्गों, विधियों, विरासत) की अधिकांश विशेषताओं वाली भाषाएँ, लेकिन एक विशिष्ट मूल रूप में। उदाहरण: ओबेरॉन (प्रोग्रामिंग भाषा) (ओबेरॉन-1 या ओबेरॉन-2)।
  • अमूर्त डेटा प्रकार समर्थन वाली भाषाएँ जिनका उपयोग वस्तु-उन्मुख प्रोग्रामिंग के समान करने के लिए किया जा सकता है, लेकिन ऑब्जेक्ट-ओरिएंटेशन की सभी विशेषताओं के बिना। इसमें ऑब्जेक्ट-आधारित|ऑब्जेक्ट-आधारित और प्रोटोटाइप-आधारित प्रोग्रामिंग|प्रोटोटाइप-आधारित भाषाएं सम्मिलित हैं। उदाहरण: JavaScript, Lua (प्रोग्रामिंग भाषा), Modula-2, CLU (प्रोग्रामिंग भाषा)।
  • गिरगिट भाषाएँ जो वस्तु-उन्मुख सहित कई प्रतिमानों का समर्थन करती हैं। TclOO के लिए इनमें से Tcl सबसे अलग है, एक हाइब्रिड ऑब्जेक्ट प्रणाली जो प्रोटोटाइप-आधारित प्रोग्रामिंग और क्लास-आधारित वस्तु-उन्मुख दोनों का समर्थन करता है।

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

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

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

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

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

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

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

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

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

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

See also: Object-oriented design

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

चार डिजाइन पैटर्न का गिरोह

Main article: Design pattern (computer science)

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

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

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

Main articles: Object-relational impedance mismatch, Object-relational mapping, and Object database

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

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

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

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

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

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

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


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

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


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

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

ठोस और GRASP दिशानिर्देश

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

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

आलोचना

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

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

The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

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

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all.

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

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

Object Oriented Programming puts the nouns first and foremost. Why would you go to such lengths to put one part of speech on a pedestal? Why should one kind of concept take precedence over another? It's not as if OOP has suddenly made verbs less important in the way we actually think. It's a strangely skewed perspective.

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

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


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

See also: Formal semantics of programming languages

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

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

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

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

यह भी देखें

प्रणाली

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

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

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

संदर्भ

  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
  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.
  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.
  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.
  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.
  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.
  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.
  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.
  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.
  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.
  28. ↑ Yegge, Steve (30 March 2006). "Execution in the Kingdom of Nouns". steve-yegge.blogspot.com. Retrieved 3 July 2010.
  29. ↑ Boronczyk, Timothy (11 June 2009). "What's Wrong with OOP". zaemis.blogspot.com. Retrieved 3 July 2010.
  30. ↑ Ambler, Scott (1 January 1998). "A Realistic Look at Object-Oriented Reuse". drdobbs.com. Retrieved 4 July 2010.
  31. ↑ Shelly, Asaf (22 August 2008). "Flaws of Object Oriented Modeling". Intel Software Network. Retrieved 4 July 2010.
  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.
  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.
  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.
  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.
  37. ↑ 37.0 37.1 Stepanov, Alexander. "STLport: An Interview with A. Stepanov". Retrieved 21 April 2010.
  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.
  40. ↑ C. J. Date, Introduction to Database Systems, 6th-ed., Page 650
  41. ↑ C. J. Date, Hugh Darwen. Foundation for Future Database Systems: The Third Manifesto (2nd Edition)
  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.
  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.
  46. ↑ "Stevey's Blog Rants: Execution in the Kingdom of Nouns". Retrieved 20 May 2020.
  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.
  52. ↑ Poll, Erik. "Subtyping and Inheritance for Categorical Datatypes" (PDF). Retrieved 5 June 2011.
  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.


अग्रिम पठन


बाहरी संबंध

Wikiquote has quotations related to Object-orientation.
Wikiversity has learning resources about ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग at
Wikibooks has a book on the topic of: Object Oriented Programming
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=ऑब्जेक्ट_ओरिएंटेड_प्रोग्रामिंग&oldid=94402’