OOP का इतिहास भूल गया

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



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

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

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

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

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

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

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

OOP के बारे में OOP पिता की राय

"मैंने" ऑब्जेक्ट-ओरिएंटेड "शब्द गढ़ा, और मैं कह सकता हूं कि मेरा मतलब सी ++ नहीं था।" एलन के, ओओपीएसएलए सम्मेलन, 1997।

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

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

जावास्क्रिप्ट और स्मॉलटॉक में बहुत कुछ है। मैं कहूंगा कि OOP की अवधारणाओं को गलत तरीके से समझने के लिए जावास्क्रिप्ट दुनिया भर में स्मालटाक का बदला है। ये दोनों भाषाएँ निम्नलिखित विशेषताओं का समर्थन करती हैं:

• ऑब्जेक्ट्स।
• प्रथम श्रेणी के कार्य और समापन।
• गतिशील प्रकार।
• देर से बाध्यकारी (कार्यों और विधियों को कार्यक्रम के निष्पादन के दौरान बदला जा सकता है)।
• ओओपी एक वर्ग-आधारित विरासत प्रणाली के बिना।

"मुझे खेद है कि मैं इस घटना के लिए" वस्तुओं "शब्द के साथ बहुत पहले आया था, क्योंकि इसका उपयोग इस तथ्य की ओर जाता है कि बहुत से लोग एक विचार को प्राथमिक महत्व देते हैं जो मुख्य रूप से उतना महत्वपूर्ण नहीं है। मुख्य विचार संदेश है। ” एलन के

2003 के एक ईमेल पत्राचार में , एलन के ने स्पष्ट किया कि जब उन्होंने स्मॉलटाक को "एक वस्तु-उन्मुख भाषा" कहा तो उनके मन में क्या था।

"मेरे लिए, ओओपी का मतलब केवल मैसेजिंग, लोकल स्टोरेज और प्रोटेक्शन और हिडिंग स्टेट और बहुत लेट बाइंडिंग है।" एलन के

दूसरे शब्दों में, एलन के के विचारों को ध्यान में रखते हुए, सबसे महत्वपूर्ण ओओपी तत्व निम्नलिखित हैं:

• संदेश सेवा।
• Encapsulation।
• गतिशील लिंकिंग।

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

ओओपी का सार

मैसेजिंग और इनकैप्सुलेशन का संयोजन कई महत्वपूर्ण उद्देश्यों को पूरा करता है:

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

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

"मुझे एहसास हुआ कि एक सेल या कंप्यूटर के लिए एक रूपक डेटा से छुटकारा पाने में मदद करेगा [...]।" एलन के

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

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

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

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

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

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

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

इस अवसर पर, कोई कह सकता है कि प्रोग्रामिंग की दुनिया कार्यात्मक प्रोग्रामिंग के लाभों को फिर से खोजती है, और वस्तु-उन्मुख भाषाओं के संदर्भ में तर्कसंगत तर्क प्रदान करती है।

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

पीएलओ में सबसे महत्वपूर्ण, एलन के के विचारों के अनुसार क्या है?

• Encapsulation।
• संदेश सेवा।
• डायनामिक बाइंडिंग (उनके निष्पादन के दौरान परिवर्तनों के विकास और अनुकूलन के लिए कार्यक्रमों की क्षमता)।

OOP में नगण्य क्या है?

• क्लासेस।
• वर्ग आधारित विरासत।
• वस्तुओं, कार्यों या डेटा से विशेष संबंध।
• कीवर्ड new
• बहुरूपता।
• स्थैतिक टाइपिंग।
• कक्षाओं को "प्रकार" के रूप में देखें।

यदि आप जावा या सी # जानते हैं, तो आप सोच सकते हैं कि स्थैतिक टाइपिंग या बहुरूपता ओओपी के सबसे महत्वपूर्ण तत्व हैं, लेकिन एलन के बीजगणितीय रूप में सार्वभौमिक व्यवहार पैटर्न से निपटने के लिए पसंद करते हैं। यहाँ हास्केल में एक उदाहरण लिखा गया है:

 fmap :: (a -> b) -> fa -> fb 

यह सार्वभौमिक map फ़न्क्टर का हस्ताक्षर है, जो अपरिभाषित प्रकारों के a और b साथ काम करता है, फ़ंक्शनल b लिए फंक्शनल के संदर्भ में a से b तक फ़ंक्शन को लागू करता है। "फ़ंक्टर" गणितीय शब्दजाल का एक शब्द है, जिसका अर्थ "प्रदर्शन संचालन के समर्थन" में घटाया गया है। यदि आप जावास्क्रिप्ट में [].map() विधि से परिचित हैं, तो आप पहले से ही जानते हैं कि इसका क्या मतलब है।

यहां जावास्क्रिप्ट के कुछ उदाहरण दिए गए हैं:

 // isEven = Number => Boolean const isEven = n => n % 2 === 0; const nums = [1, 2, 3, 4, 5, 6]; //  map   `a => b`    `a` ( `this`) //     `b` //    `a`   `Number`,   `b`  `Boolean` const results = nums.map(isEven); console.log(results); // [false, true, false, true, false, true] 

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

 // matches = a => Boolean //  `a`    ,   const matches = control => input => input === control; const strings = ['foo', 'bar', 'baz']; const results = strings.map(matches('bar')); console.log(results); // [false, true, false] 

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

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

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

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

यदि प्रतिबंध आपके कोड को सरल बनाते हैं - महान! लेकिन अगर बाधाएं आपको अधिक जटिल कोड लिखने के लिए मजबूर करती हैं, तो शायद इन बाधाओं के साथ कुछ गलत है।

"वस्तु" क्या है?

शब्द "वस्तु", समय के साथ, अर्थ के कई माध्यमिक अर्थों को प्राप्त कर चुका है। जिसे हम जावास्क्रिप्ट में "ऑब्जेक्ट्स" कहते हैं, वह केवल मिश्रित डेटा प्रकार हैं, बिना किसी क्लास-आधारित प्रोग्रामिंग या एलन का के संदेश पासिंग विचारों के किसी भी संकेत के बिना।

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

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

एक वस्तु सिर्फ एक समग्र डेटा संरचना है, और इसे एक वस्तु माना जाने के लिए कुछ विशेष की आवश्यकता नहीं है। हालाँकि, ऑब्जेक्ट का उपयोग करके प्रोग्रामिंग इस तथ्य की ओर नहीं ले जाती है कि इस तरह के कोड "ऑब्जेक्ट-ओरिएंटेड" हो जाते हैं, ठीक उसी तरह जैसे कि फ़ंक्शंस का उपयोग करके कोड "कार्यात्मक" नहीं बनता है।

OOP अब एक वास्तविक OOP नहीं है

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

यहाँ वास्तविक OOP क्या है:

• घटकों का उपयोग करते हुए प्रोग्रामिंग (एलन Kay उन्हें "ऑब्जेक्ट" कहते हैं)।
• घटक की स्थिति को संक्षिप्त किया जाना चाहिए।
• संस्थाओं के बीच संचार के लिए, संदेश का उपयोग किया जाता है।
• घटकों को जोड़ा जा सकता है, संशोधित किया जा सकता है और रनटाइम पर प्रतिस्थापित किया जा सकता है।

अधिकांश वस्तु व्यवहारों को बीजगणितीय डेटा संरचनाओं का उपयोग करके सार्वभौमिक तरीके से परिभाषित किया जा सकता है। वंशानुक्रम की कोई आवश्यकता नहीं है। घटक अपने डेटा को सार्वजनिक किए बिना सार्वजनिक कार्यों और आयात मॉड्यूल से व्यवहार का पुन: उपयोग कर सकते हैं।

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

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

एक अच्छा एमओपी कैसा दिखता है?

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

इन प्रणालियों में से प्रत्येक के संचालन का समर्थन करने के लिए, लंबे समय तक रहने वाली प्रक्रियाएं, जैसे कि घटना श्रोताओं की आवश्यकता हो सकती है। यहां आपको एप्लिकेशन की स्थिति की आवश्यकता होगी - नेटवर्क कनेक्शन के बारे में कुछ जानकारी संग्रहीत करने के लिए, इंटरफ़ेस नियंत्रण के साथ मामलों की स्थिति के बारे में और एप्लिकेशन के बारे में ही।

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

इस बीच, नेटवर्क कनेक्शन के लिए जिम्मेदार घटक नेटवर्क पर किसी अन्य कंप्यूटर के उपयोगकर्ता के कनेक्शन की निगरानी कर सकता है, संदेश सुन सकता है, और इसे रिमोट मशीन पर सहेजने के लिए राज्य के एक अद्यतन दृश्य को भेज सकता है। इस तरह के एक घटक नेटवर्क तंत्र के साथ काम करने के लिए जिम्मेदार है, इस बारे में जानता है कि कनेक्शन काम करता है या नहीं, और इसी तरह।

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

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

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

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

यह सॉफ्टवेयर की दुनिया के लिए एक असफल वर्ग-आधारित विरासत प्रयोग से खुद को मुक्त करने और गणितीय और वैज्ञानिक सिद्धांतों को अपनाने का समय है जो ओओपी में सबसे आगे थे।

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

इसलिए, यदि प्रोग्रामर के शब्दजाल से एक शब्द "एमओपी" नहीं लगता है, तो निराश न हों। उपरोक्त एमओपी सिद्धांतों के साथ बस अपने ओओपी को साफ करें।