वे ऐतिहासिक स्थितियाँ क्या थीं जिनके कारण ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग एक प्रमुख प्रोग्रामिंग प्रतिमान बन गया?

Question

क्या कुछ आर्थिक (और अन्य ऐतिहासिक) कारक थे जिनके कारण ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग लैंग्वेज प्रभावशाली हो गई थीं? मुझे पता है कि सिमुला ने चीजों को बंद कर दिया था, लेकिन क्या व्यापार की बढ़ती जरूरतों के कारण ओओपी भाषाओं को अपनाया गया था? या, OOP भाषाओं के साथ हो सकने वाली नई चीजों के कारण गोद लेना था?

संपादित करें कि मैं वास्तव में सबसे ज्यादा दिलचस्पी रखता हूं कि क्या बाहरी भाषाओं के लिए कुछ कारक हैं जो उन्हें पकड़ने की अनुमति देते हैं।

Comments

यह समझ में आता है, लेकिन मुझे लगता है कि मैं उन बाहरी परिस्थितियों में अधिक रुचि रखता था जो विकास के दौरान चल रहे थे। यह बहुत अच्छी तरह से हो सकता है कि बाहरी कारकों का एक सीमित प्रभाव था।

मैं आपको गारंटी देता हूं कि यहां तक ​​कि बाहरी कारकों के बारे में एक सवाल के लिए, programmers.stackexchange एक बेहतर स्थान है। इसमें एक टन ऐसे लोग हैं जो उद्योग में सक्रिय रूप से काम करते हैं और कई ऐसे हैं जो इस उद्योग से हट गए हैं। आपको ऐसे व्यक्ति की तलाश करने की अधिक संभावना होगी जो आपके प्रश्न का उत्कृष्ट उत्तर यहाँ से देता है।

— ऑप्ट

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

— मेसन व्हीलर

बाहरी प्रभाव के रूप में फिट हो सकती हैं लेगो टॉय ईंटें ...

— जेमी एफ

@ मेसन: यह सुनिश्चित नहीं है कि सिमाला और स्मॉलटॉक मॉडल क्या विभाजित करते हैं। रूबी को कहां रखोगे? LUA? अजगर? जावास्क्रिप्ट?

— केविन क्लाइन

Answer 1

संक्षिप्त जवाब

मुझे लगता है कि यह OO दिनों से पहले सॉफ्टवेयर परियोजनाओं का मंथन था। ओओ ने मौलिक रूप से महत्वपूर्ण अवधारणा को जोड़कर मदद की - वास्तविक दुनिया का मॉडल ।

---

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

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

अधिकांश व्यावसायिक वातावरण में सॉफ्टवेयर विकास में सबसे महत्वपूर्ण तत्व परियोजना प्रबंधन था। तंग और कम से कम अनुमानित बजट की सख्त जरूरत थी और यह सुनिश्चित करने के लिए कि परियोजना को अंतिम रूप से अंतिम पंक्ति तक पहुंचाना है। इस अवधि के दौरान 1975 में पौराणिक मानवमूल्यों में से एक था।

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

अधिक परिप्रेक्ष्य के लिए कुछ संदर्भ - http://journal.thedacs.com/issue/43/88

तो क्यों OO?

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

EDIT
मैं यह भी जोड़ूंगा कि प्रोग्रामिंग लैंग्वेज ऐसी मौलिक अवधारणाओं (OO प्रतिमान, पहलू, आभासी मशीनों) के समानांतर एक साथ विकसित हुई हैं, प्रत्येक नई अवधारणा और ताजा सोच केवल तभी सामने आई है जब एक नई नई प्रोग्रामिंग भाषाओं ने इसमें महारत हासिल की - केवल परिचित लेकिन मूल सिद्धांतों से दूर रहें कोर! एक ही समय में - ये नई अवधारणा और नई भाषाएँ केवल नई व्यावसायिक समस्याओं के कारण उभरी हैं। 1980 का - बड़े पैमाने पर सॉफ्टवेयर के लिए OO, इंटरनेट युग में 1990 जावा, PHP / ASP और वेब के लिए कई अन्य। प्रोग्रामिंग लैंग्वेज में इनोवेशन भी ज्यादातर बाजार की जरूरत के हिसाब से चलाए जा रहे थे।

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

Comments

शिफ्ट का बैक्टीरिया क्या था और कहां जाना था? 70 के दशक का अंत। क्या बनाने वाले डेवलपर्स जाने के लिए समय को समझते हैं? प्रक्रियात्मक से थक गया, हाँ, लेकिन विकल्प के चचेरे भाई के पास होना चाहिए?

— स्वतंत्र

@ जोनास - ठीक है - जवाब में संशोधन किया।

— दीपन मेहता

जहां तक ​​ऐतिहासिक सफलता का हम मूल्यांकन कर रहे हैं- हम निश्चित रूप से कह सकते हैं कि परिचित कुछ भूमिका निभाता है। C (B का उत्तराधिकारी) था, C ++ एक बेहतर C था, जबकि OO माना जाता था कि यह एक प्रतिमान है। यहां तक ​​कि जावा भी C ++ से तैयार कूद था (जो C ++ समस्याओं के बिना C ++ की तरह अधिक था। मेमोरी और पोर्टेबिलिटी)। इनमें से अधिकांश भाषाओं ने मौजूदा स्थान को अधिक प्रभावी ढंग से प्राप्त करके चासम को पार कर लिया, भले ही उनमें कुछ अधिक मौलिक था। अधिक इसलिए, क्योंकि हर भाषा कुछ प्रोग्रामर का अधिग्रहण करेगी जो पहले से ही कुछ अन्य प्रोग्रामिंग भाषाओं को जानते हैं। लेकिन यह हमेशा सच नहीं हो सकता है!

— दीपन मेहता

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

— दीपन मेहता

"वास्तविक दुनिया का मॉडल" निर्णायक लगता है, लेकिन ज्यादातर मामलों में, ऐसा नहीं होता है। Customerवर्ग की तरह विधि नहीं है eatLunch, goToWorkया sleep, हालांकि यह है कि क्या ग्राहकों में क्या है, असली दुनिया । Productवर्ग, कई तरीके है, हालांकि ज्यादातर उत्पादों में सब पर वास्तव में कोई व्यवहार है असली दुनिया । इसलिए, मैं तर्क दूंगा कि OO मॉडल केवल गुणों के मामले में (अधिक-या-कम) मेल खाता है, लेकिन वास्तविक दुनिया के साथ व्यवहार के मामले में बिल्कुल नहीं। लेकिन आपको ओओ की जरूरत नहीं है कि एक डेटा मॉडल हो जो वास्तविक दुनिया की वस्तुओं से मेल खाता हो। रिकॉर्ड प्रकार यह सब लेता है।

— user281377

Answer 2

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

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

Answer 3

मैं OOP को प्रक्रियात्मक कोड से एक प्राकृतिक विकासवादी कदम के रूप में देखता हूं:

1. प्रक्रियात्मक कोड: मशीन को A करने के लिए कहें, फिर उसे B करने के लिए कहें।
2. OOP: इंटरफेस / इनपुट / आउटपुट को परिभाषित करके प्रक्रियात्मक निर्देशों को बहुत ही पुन: प्रयोज्य विखंडू में पैकेज करें। (चेतावनी: सरलीकरण)

मुझे यकीन है कि कोई व्यापक दृष्टिकोण वाला कोई व्यक्ति इसमें झंकार करेगा, लेकिन ऐसा लगता है कि यह प्रोग्रामर को कोड को तेज़ी से उत्पन्न करने की अनुमति देने में एक स्वाभाविक प्रगति थी: यानी अधिक से अधिक कोड का पुन: उपयोग करने की अनुमति।

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

Answer 4

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

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

फिर कुछ अन्य लोग आए जिन्होंने कहा कि आपको यहां और वहां बहुत सारे कोड दोहराने की आवश्यकता थी और यह एक दुःस्वप्न था कि कोड को पुन: उपयोग करने का एक तरीका ईजाद किया जाए। लोग कोड के पुन: प्रयोज्य बिट्स को परिसीमन करने के लिए प्रक्रियाओं और कार्यों के साथ आए। इसने एनकैप्सुलेशन और एकल जिम्मेदारी सिद्धांतों को भी जन्म दिया।

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