तो * * एलन का क्या वास्तव में "वस्तु उन्मुख" शब्द से मतलब था?


95

कथित तौर पर, एलन काय शब्द "ऑब्जेक्ट ओरिएंटेड" का आविष्कारक है। और वह अक्सर कहा जाता है कि आज हम जिसे ओओ कहते हैं, वह उसका मतलब नहीं है।

उदाहरण के लिए, मैंने इसे Google पर पाया:

मैंने 'ऑब्जेक्ट-ओरिएंटेड' शब्द बनाया है, और मैं आपको बता सकता हूं कि मेरे पास सी ++ नहीं था

- एलन के, OOPSLA '97

मुझे लगता है कि वह क्या मतलब था के बारे में कुछ बहुत व्यावहारिक सुनकर याद है। "संदेश गुजर" की तर्ज पर कुछ।

क्या आप जानते हैं कि उसका क्या मतलब था? क्या आप इस बात का अधिक विवरण भर सकते हैं कि उसका क्या मतलब था और यह आज के सामान्य OO से कैसे भिन्न है? यदि आपके पास कोई संदर्भ है तो कृपया साझा करें।

धन्यवाद।


आपको मेरा ब्लॉग पोस्ट इस विषय पर दिलचस्प लग सकता है: yegor256.com/tag/oop.html
yegor256

इस ब्लॉग पोस्ट के कमेंट सेक्शन की जाँच करें, जहाँ एलन के खुद सवालों के जवाब देते हैं: एलन
काय

जवाबों:


82

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en


दिनांक: बुध, 23 जुलाई 2003 09:33:31 -0800 To: स्टीफन राम [गोपनीयता के लिए हटा दिया गया] से: एलन Kay [गोपनीयता के लिए हटा दिया गया] विषय: पुन: "ऑब्जेक्ट-ओरिएंटेड" का स्पष्टीकरण

हाय स्टीफन -

देरी के लिए क्षमा करें, लेकिन मैं छुट्टी पर था।

6:27 बजे +0200 7/17/03, स्टीफन राम ने लिखा:

प्रिय डॉ। काय,

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

मुझे पूरा यकीन है कि मैंने किया।

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

रिकॉर्ड के लिए, मेरा ट्यूटोरियल पेज, और आगे वितरण और प्रकाशन आपको समझा सकता है:

"ऑब्जेक्ट-ओरिएंटेड" शब्द का प्रयोग कब और कहाँ किया गया था?

यूटा में कुछ समय बाद ६६ के बाद जब स्केचपैड, सिमुला से प्रभावित, ARPAnet के लिए डिज़ाइन, बरोज़ B5000, और जीव विज्ञान और गणित में मेरी पृष्ठभूमि, मैंने प्रोग्रामिंग के लिए एक वास्तुकला के बारे में सोचा। यह शायद 1967 में था जब किसी ने मुझसे पूछा कि मैं क्या कर रहा था, और मैंने कहा: "यह ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग है"।

इसके मूल गर्भाधान के निम्नलिखित भाग थे।

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

  • मैं डेटा से छुटकारा पाना चाहता था। B5000 ने लगभग अपनी अविश्वसनीय HW वास्तुकला के माध्यम से ऐसा किया। मुझे एहसास हुआ कि सेल / पूरे-कंप्यूटर रूपक को डेटा से छुटकारा मिल जाएगा, और यह कि "<-" सिर्फ एक और संदेश टोकन होगा (यह सोचने के लिए मुझे काफी समय लगा क्योंकि मुझे वास्तव में इन सभी प्रतीकों के नाम के रूप में सोचा गया था कार्यों और प्रक्रियाओं।

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

  • मुझे यह पसंद नहीं आया कि जिस तरह से सिमुला I या सिमूला 67 ने वंशानुक्रम किया (हालांकि मुझे लगा कि न्यागार्ड और डाहल सिर्फ जबरदस्त विचारक और डिजाइनर थे)। इसलिए मैंने अंतर्निहित विशेषता के रूप में विरासत को छोड़ने का फैसला किया, जब तक कि मैंने इसे बेहतर नहीं समझा।

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

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

ज़ेरॉक्स PARC में मूल स्मॉलटॉक ऊपर से निकला। इसके बाद के स्मॉलटाक की हिस्ट्री चैप्टर के अंत में शिकायत की जाती है: वे सिमूला की ओर पीछे हट गए और विस्तार तंत्र को सुरक्षित लोगों के साथ प्रतिस्थापित नहीं किया, जो कहीं भी उपयोगी थे।

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

(मैं प्रकारों के खिलाफ नहीं हूं, लेकिन मैं किसी भी प्रकार के सिस्टम के बारे में नहीं जानता, जो पूरी तरह से दर्द नहीं हैं, इसलिए मुझे अभी भी गतिशील टाइपिंग पसंद है।)

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

[इसके अलावा,] मुझे जिन चीजों का उल्लेख करना चाहिए उनमें से एक यह है कि सिमुला द्वारा उत्प्रेरित दो मुख्य रास्ते थे। शुरुआती (बस दुर्घटना से) बायो / नेट गैर-डेटा-प्रक्रिया मार्ग था जो मैंने लिया था। अन्य एक, जो अध्ययन के एक उद्देश्य के रूप में थोड़ी देर बाद आया था, डेटा प्रकार था, और यह बहुत अधिक खेल मिला।

यदि हम पूरे इतिहास को देखें, तो हम देखते हैं कि आद्य-ओओपी सामान की शुरुआत ADT से हुई, मैंने "ऑब्जेक्ट्स" नामक एक छोटे से कांटे को - जिसके कारण स्मॉलटाक, आदि को जन्म दिया, - लेकिन छोटे कांटे के बाद। CS स्थापना ने बहुत ADT किया और डेटा-प्रक्रिया प्रतिमान के साथ रहना चाहता था। ऐतिहासिक रूप से, यह USAF Burroughs 220 फाइल सिस्टम (जिसे मैंने स्मॉलटॉक इतिहास में वर्णित किया है) को देखने के लायक है, MIT (AED और पहले) में डौग रॉस का प्रारंभिक कार्य जिसमें उन्होंने डेटा संरचनाओं में एम्बेडिंग प्रक्रिया बिंदुओं की वकालत की, स्केचपैड (जो था) पूर्ण बहुरूपता - जहाँ उदाहरण के लिए इसके डेटा संरचना में समान ऑफसेट का अर्थ "प्रदर्शन" होता है और उस वस्तु के प्रकार के लिए उपयुक्त दिनचर्या के लिए एक संकेतक होगा जो संरचना का प्रतिनिधित्व करता है, आदि, और बरोज B5000। जिनकी प्रोग्राम रेफरेंस टेबल "बड़ी वस्तुएं" सही थीं और "डेटा" और "प्रक्रिया" दोनों की ओर संकेत करती थीं, लेकिन अक्सर सही काम कर सकती थीं यदि यह डेटा के बाद जाने की कोशिश कर रहा था और एक प्रक्रिया सूचक पाया गया। और बहुत ही पहली समस्याएं जो मैंने अपने शुरुआती यूटा सामान के साथ हल की थीं, केवल विधियों और वस्तुओं का उपयोग करके "डेटा का गायब होना" था। 60 के दशक के अंत में (मुझे लगता है) बॉब बाल्ज़र ने "डटलस प्रोग्रामिंग" नामक एक सुंदर निफ्टी पेपर लिखा, और उसके तुरंत बाद जॉन रेनॉल्ड्स ने एक समान रूप से निफ्टी पेपर "गेदेंकेन" लिखा (1970 में मुझे लगता है कि जिसमें उन्होंने दिखाया कि लैम्डा का उपयोग करना सही तरीके से अभिव्यक्तियाँ डेटा को प्रक्रियाओं द्वारा सारगर्भित करने की अनुमति देंगी। लेकिन अक्सर सही काम कर सकता है अगर यह डेटा के बाद जाने की कोशिश कर रहा था और एक प्रक्रिया सूचक पाया गया। और बहुत ही पहली समस्याएं जो मैंने अपने शुरुआती यूटा सामान के साथ हल की थीं, केवल विधियों और वस्तुओं का उपयोग करके "डेटा का गायब होना" था। 60 के दशक के अंत में (मुझे लगता है) बॉब बाल्ज़र ने "डटलस प्रोग्रामिंग" नामक एक सुंदर निफ्टी पेपर लिखा, और उसके तुरंत बाद जॉन रेनॉल्ड्स ने एक समान रूप से निफ्टी पेपर "गेदेंकेन" लिखा (1970 में मुझे लगता है कि जिसमें उन्होंने दिखाया कि लैम्डा का उपयोग करना सही तरीके से अभिव्यक्तियाँ डेटा को प्रक्रियाओं द्वारा सारगर्भित करने की अनुमति देंगी। लेकिन अक्सर सही काम कर सकता है अगर यह डेटा के बाद जाने की कोशिश कर रहा था और एक प्रक्रिया सूचक पाया गया। और बहुत ही पहली समस्याएं जो मैंने अपने शुरुआती यूटा सामान के साथ हल की थीं, केवल विधियों और वस्तुओं का उपयोग करके "डेटा का गायब होना" था। 60 के दशक के अंत में (मुझे लगता है) बॉब बाल्ज़र ने "डटलस प्रोग्रामिंग" नामक एक सुंदर निफ्टी पेपर लिखा, और उसके तुरंत बाद जॉन रेनॉल्ड्स ने एक समान रूप से निफ्टी पेपर "गेदेंकेन" लिखा (1970 में मुझे लगता है कि जिसमें उन्होंने दिखाया कि लैम्डा का उपयोग करना सही तरीके से अभिव्यक्तियाँ डेटा को प्रक्रियाओं द्वारा सारगर्भित करने की अनुमति देंगी।

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

चीयर्स,

एलन के


1
HTTP / 1.1 403 प्रवेश निषेध।
जॉब

1
मैं इसे एक्सेस करने में सक्षम था, इसलिए यह एक क्षणिक समस्या रही होगी। उस लिंक के लिए धन्यवाद, मनोज।
डेविड कॉनरैड

2
@ जोब बुधवार (16 मार्च, जिस दिन आपको जाहिरा तौर पर 403 त्रुटि मिली थी) userpage.fu-berlin.de पर डोमेन व्यवस्थापक का मासिक सेवा दिवस है। वे नियमित रूप से महीने में एक बार नेटवर्क के कुछ हिस्सों को ऑफलाइन लेते हैं। उह, हाँ, मत पूछो ...
कोनराड रूडोल्फ

क्या आप / कोई स्पष्ट कर सकता है कि "मैं डेटा से छुटकारा चाहता था" से क्या मतलब है? डेटा OO का एक अभिन्न अंग है (अर्थात इसे अक्सर किसी कक्षा में समझाया जाता है, या कक्षाओं से / के आसपास पास किया जाता है), और जो भी प्रतिमान का उपयोग किया जाता है, कोई भी कंप्यूटिंग में डेटा के बिना नहीं कर सकता है, इसलिए डेटा से छुटकारा पाने का कोई मतलब नहीं है ।
डेनिस

1
<- मूल
स्मॉलटैक

22

सबसे ज्यादा अगर ऑब्जेक्ट-ओरिएंटेशन का मतलब एलन के से नहीं है, तो स्मॉलटाक भाषा में सन्निहित है।

इसके अलावा, http://en.wikipedia.org/wiki/Message_passing#Influences_on_other_programming_models से :

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

18
एक तो आश्चर्य होता है कि उसने इसे "संदेश-उन्मुख" के बजाय "ऑब्जेक्ट-ओरिएंटेड" क्यों कहा।
डेविड थॉर्नले

@ डेविड थॉर्नले: ताकि C ++ विधि-उन्मुख बने?
back2dos

60
मैं 60 के दशक में वापस शब्द के बारे में बहुत अधिक था और उसे "संदेश उन्मुख" जैसा कुछ चुनना चाहिए था
एलन के

1
लेकिन "संदेश उन्मुख" तब क्या है? (मैं async कॉल (संभवतः) के बारे में सोच सकता हूं, लेकिन वास्तव में किसी भी भाषा को अधिक-या-कम "सामान्य" तरीकों को लागू नहीं करने के बारे में नहीं जानता; इसमें वापसी मूल्यों के बारे में भी एक बात है, लेकिन यह सॉर्ट-ऑफ के साथ छल किया जा सकता है ' रेफरी / 'आउट' पैरामीटर या ऐसा कुछ)
mlvljr

1
"संदेश उन्मुख" मूल रूप से देर से बाध्यकारी / गतिशील-टाइपिंग है - वस्तु को दिया गया संदेश रनटाइम पर (उस वस्तु द्वारा) विश्लेषण किया जाता है।
मार्क सिडेड

6

सबसे ज्यादा अगर ऑब्जेक्ट-ओरिएंटेशन का मतलब एलन के से नहीं है, तो स्मॉलटाक भाषा में सन्निहित है।

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

एलन Kay की टिप्पणी से लिया गया:

http://computinged.wordpress.com/2010/09/11/moti-asks-objects-never-well-hardly-ever/


आपको टिप्पणियों के लिए एक लंबा रास्ता तय करना है, यहाँ एलन के की टिप्पणी का सीधा लिंक है: कंप्यूटिंग
ed.wordpress.com/2010/09/11/…

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

5

उन प्रमुख बिंदुओं में से एक जो मैंने एलन के और अन्य लोगों जैसे जिम कोपलीन के कार्यों का अनुसरण करने से उठाया है, वह यह है कि सच्चा "ऑब्जेक्ट" ओरिएंटेड प्रोग्रामिंग ह्यूमैन / यूएसईआर मानसिक मॉडल के बजाय मॉडलिंग कंप्यूटर और सॉफ्टवेयर के बारे में है, बजाय PROGRAMMERS के लिए सिर्फ एक उपकरण।

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

जावास्क्रिप्ट में अवधारणा के प्रमाण के रूप में इसके कुछ संस्करण का प्रयास करने की मेरी योजनाओं के बारे में एक पोस्ट है: http://www.cemetech.net/forum/viewtopic.php?p=234494#234494

सॉफ्टवेयर डेवलपमेंट / प्रोग्रामिंग के नजरिए से, जिम कोपलियन इस बारे में बात करते हैं कि कोड और SHOULD किस तरह से यूजर्स के मानसिक मॉडल से मिलते जुलते हैं। यही है, कोड बहुत ही उसी तरह से पढ़ता है जैसे कि यह किसी व्यक्ति द्वारा इसे व्यवहार का वर्णन करके ध्वनि करेगा। यह बड़े पैमाने पर OBJECTS के संदर्भ में सोचने के द्वारा पूरा किया गया है, न कि CLASSES और TYPES के संदर्भ में। व्यवहार का वर्णन वस्तुओं द्वारा निभाई जाने वाली रॉल्स की शर्तों पर किया जाता है, न कि किसी वस्तु की पहचान की परिभाषा के भाग के रूप में। आपको वस्तुओं के संदर्भ में इंटरैक्शन को मॉडल करने में सक्षम होना चाहिए, जो कि वे जिस बातचीत में खेलते हैं, उसके द्वारा पहचाने जाते हैं। यह है कि मानव मानसिक मॉडल कैसे काम करते हैं: वेटर, ग्राहक, खजांची, स्रोत खाता, गंतव्य खाता, ... ये रोल्स हैं, न कि TYPES, और आप "जो भी वस्तु इस समय इस भूमिका को निभा रही है" के लिए तरीकों को परिभाषित करने में सक्षम हैं। ",


डीडीडी समान अवधारणाओं का उपयोग करता है। शायद आप इस बारे में सही हैं। :-)
inf3rno
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.