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

From Vigyanwiki
(Created page with "{{short description|Programming paradigm based on the concept of objects}} {{Redirect|Object-oriented|other meanings of object-oriented|Object-orientation}} {{Use dmy dates|da...")
 
Line 191: Line 191:


== ओओपी भाषाएं ==
== ओओपी भाषाएं ==
{{Unreferenced section|date=August 2009}}
{{See also|List of object-oriented programming languages}}
{{See also|List of object-oriented programming languages}}
सिमुला (1967) को आम तौर पर वस्तु-उन्मुख भाषा की प्राथमिक विशेषताओं वाली पहली भाषा के रूप में स्वीकार किया जाता है। यह [[कंप्यूटर सिमुलेशन]] बनाने के लिए बनाया गया था, जिसमें वस्तुओं को सबसे महत्वपूर्ण सूचना प्रतिनिधित्व कहा जाने लगा। स्मॉलटाक (1972 से 1980) एक और प्रारंभिक उदाहरण है, और वह जिसके साथ ओओपी के अधिकांश सिद्धांत विकसित किए गए थे। वस्तु अभिविन्यास की डिग्री के संबंध में, निम्नलिखित भेद किए जा सकते हैं:
सिमुला (1967) को आम तौर पर वस्तु-उन्मुख भाषा की प्राथमिक विशेषताओं वाली पहली भाषा के रूप में स्वीकार किया जाता है। यह [[कंप्यूटर सिमुलेशन]] बनाने के लिए बनाया गया था, जिसमें वस्तुओं को सबसे महत्वपूर्ण सूचना प्रतिनिधित्व कहा जाने लगा। स्मॉलटाक (1972 से 1980) एक और प्रारंभिक उदाहरण है, और वह जिसके साथ ओओपी के अधिकांश सिद्धांत विकसित किए गए थे। वस्तु अभिविन्यास की डिग्री के संबंध में, निम्नलिखित भेद किए जा सकते हैं:

Revision as of 10:37, 19 February 2023

"Object-oriented" redirects here. For other meanings of object-oriented, see Object-orientation.

Programming paradigms

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

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

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

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

इतिहास

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

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

एलन के ने बाद में 1966 में अपनी सोच पर एक मजबूत प्रभाव के रूप में LISP इंटर्नल्स की विस्तृत समझ का हवाला दिया।[5]

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning – it took a while to see how to do messaging in a programming language efficiently enough to be useful).

Alan Kay, [5]

एक और प्रारंभिक एमआईटी उदाहरण 1960-1961 में इवान सदरलैंड द्वारा बनाया गया स्केचपैड था; स्केचपैड के बारे में अपने शोध प्रबंध पर आधारित 1963 की तकनीकी रिपोर्ट की शब्दावली में, सदरलैंड ने वस्तु और उदाहरण की धारणाओं को परिभाषित किया (मास्टर या परिभाषा द्वारा कवर की गई वर्ग अवधारणा के साथ), हालांकि ग्राफिकल इंटरैक्शन के लिए विशेष।[6] साथ ही, एक MIT 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 में, बर्ट्रेंड मेयर ने एफिल (प्रोग्रामिंग भाषा) का पहला डिज़ाइन भी तैयार किया। सॉफ्टवेयर गुणवत्ता पर केंद्रित, एफिल विशुद्ध रूप से वस्तु-उन्मुख प्रोग्रामिंग भाषा है और संपूर्ण सॉफ्टवेयर जीवनचक्र का समर्थन करने वाला एक संकेत है। मेयर ने वस्तु-उन्मुख सॉफ्टवेयर निर्माण में सॉफ्टवेयर इंजीनियरिंग और कंप्यूटर साइंस से कुछ प्रमुख विचारों के आधार पर एफिल सॉफ्टवेयर डेवलपमेंट मेथड का वर्णन किया। एफिल की गुणवत्ता पर ध्यान केंद्रित करने के लिए अनिवार्य है मेयर की विश्वसनीयता तंत्र, अनुबंध द्वारा डिजाइन, जो विधि और भाषा दोनों का एक अभिन्न अंग है।

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

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

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

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

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

विशेषताएं

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग ऑब्जेक्ट्स का उपयोग करती है, लेकिन सभी संबद्ध तकनीकों और संरचनाओं को सीधे उन भाषाओं में समर्थित नहीं किया जाता है जो OOP का समर्थन करने का दावा करती हैं। यह ऑपरेंड पर ऑपरेशन करता है। नीचे सूचीबद्ध विशेषताएं उन भाषाओं में आम हैं जिन्हें दृढ़ता से वर्ग- और ऑब्जेक्ट-ओरिएंटेड (या OOP समर्थन के साथ बहु-प्रतिमान) माना जाता है, उल्लेखनीय अपवादों का उल्लेख किया गया है।[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) एक और प्रारंभिक उदाहरण है, और वह जिसके साथ ओओपी के अधिकांश सिद्धांत विकसित किए गए थे। वस्तु अभिविन्यास की डिग्री के संबंध में, निम्नलिखित भेद किए जा सकते हैं:

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

गतिशील भाषाओं में ओओपी

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

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

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

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

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

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


ओओपी और नियंत्रण प्रवाह

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


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

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

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

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

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

आलोचना

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

Luca Cardelli ने दावा किया है कि OOP कोड प्रक्रियात्मक कोड की तुलना में आंतरिक रूप से कम कुशल है, OOP को संकलित करने में अधिक समय लग सकता है, और यह कि OOP भाषाओं में वर्ग विस्तार और संशोधन के संबंध में बेहद खराब मॉड्यूलरिटी गुण हैं, और यह बेहद जटिल हैं।[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.

पोटोक एट अल द्वारा एक अध्ययन। OOP और प्रक्रियात्मक दृष्टिकोण के बीच उत्पादकता में कोई महत्वपूर्ण अंतर नहीं दिखाया है।[39] क्रिस्टोफर जे. डेट ने कहा कि ओओपी की अन्य तकनीकों से महत्वपूर्ण तुलना, विशेष रूप से संबंधपरक, ओओपी की एक सहमत और कठोर परिभाषा की कमी के कारण कठिन है;[40] हालाँकि, डेट और डार्वेन ने OOP पर एक सैद्धांतिक आधार प्रस्तावित किया है जो RDBMS का समर्थन करने के लिए OOP को एक प्रकार के अनुकूलन योग्य डेटा प्रकार के रूप में उपयोग करता है।[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.

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

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

यह भी देखें

सिस्टम

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

संदर्भ

  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). 5 January 2023. Retrieved 17 January 2023.
  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=94399’