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

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

एर्लैंग की बढ़ती लोकप्रियता के साथ, वे अक्सर सवाल पूछने लगे, "क्या एरलैंग वस्तु-उन्मुख है?" सही उत्तर होगा "- आप क्या हैं, नहीं!"। लेकिन हम पूरी आवाज में ऐसा नहीं कह सकते थे, इसलिए हमें बाहर निकलना पड़ा। हम कुछ बहुत ही गैर-तुच्छ उत्तरों के साथ आए, जो एर्लांग को एक प्रकार-वस्तु उन्मुख भाषा के रूप में प्रस्तुत करेंगे (उन लोगों के लिए जो इस प्रश्न के साथ सबसे अधिक संभावना रखते हैं), लेकिन उन लोगों के लिए भी वस्तु-उन्मुख नहीं हैं जो वास्तव में इस विषय में हैं।

यहां मैं तार्किक प्रोग्रामिंग पर 7 वें IEEE सम्मेलन में फ्रेंच आईबीएम के निदेशक की थीसिस को याद करना चाहता हूं। उन्होंने कहा कि आईबीएम ने प्रोलॉग के लिए कई ऑब्जेक्ट-ओरिएंटेड एक्सटेंशन जोड़े हैं। जब उनसे इसके कारणों के बारे में पूछा गया, तो उन्होंने कहा:

"- हमारे ग्राहक एक वस्तु-उन्मुख प्रोलॉग चाहते थे, इसलिए हमने एक वस्तु-उन्मुख प्रोलॉग बनाया"

मुझे याद है, मैंने सोचा, “कितना अच्छा! यह सरल है, कोई पछतावा नहीं है, कोई आत्मनिरीक्षण नहीं है, यह सही करने के लिए कोई फेंक नहीं है। "

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

OOP के विषय पर मेरी व्यक्तिगत आपत्तियाँ इसके मुख्य प्रावधानों के दावे हैं। मैं इनमें से कुछ प्रावधानों और मेरे दावों के सार पर प्रकाश डालूंगा।

आपत्ति नं १। डेटा संरचनाओं और कार्यों को एक दूसरे से बंधा नहीं होना चाहिए।

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

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

डेटा संरचनाएं बस मौजूद हैं। वे कोई कार्रवाई नहीं करते हैं। वे विशेष रूप से घोषणात्मक हैं। फ़ंक्शन को "समझने" की तुलना में डेटा संरचना "समझना" कई बार आसान है।

कार्यों को आउटपुट में इनपुट बदलने वाले ब्लैक बॉक्स द्वारा दर्शाया गया है। यदि मैं इनपुट और आउटपुट को समझता हूं, तो मैं फ़ंक्शन को समझ सकता हूं (हालांकि इसका मतलब यह नहीं है कि मैं इस फ़ंक्शन को लिख सकता हूं)।

फ़ंक्शंस को आमतौर पर एक कंप्यूटर सिस्टम के भागों के रूप में "समझा" जाता है जो टाइप T1 के डेटा संरचना से डेटा टाइप T2 के डेटा संरचना में स्थानांतरित करता है।

चूंकि फ़ंक्शंस और डेटा संरचनाएं पूरी तरह से विभिन्न प्रकार के जानवर हैं, इसलिए उन्हें "सेल" में रखने का निर्णय मौलिक रूप से गलत है।

आपत्ति नं। २। प्रत्येक वस्तु एक वस्तु होनी चाहिए

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

-deftype day() = 1..31 -deftype month() = 1..12. -deftype year() = int(). -deftype hour() = 1..24. -deftype minute() = 1..60. -deftype second() = 1..60. -deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}. -deftype hms() = {hms, hour(), min(), sec()}. ... 

ध्यान दें कि ये परिभाषाएँ किसी विशेष वस्तु से संबंधित नहीं हैं। वे आमतौर पर किसी भी प्रतिबंध के बिना उपयोग किए जाते हैं, इसलिए "समय" का प्रतिनिधित्व करने वाली ऐसी डेटा संरचनाएं किसी भी फ़ंक्शन द्वारा उपयोग की जा सकती हैं।

इसके अलावा, उनके पास कोई संबद्ध विधि नहीं है।

आपत्ति संख्या 3। ऑब्जेक्ट-ओरिएंटेड भाषाओं में, टाइप परिभाषाएँ सर्वव्यापी हैं

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं में, डेटा प्रकार की परिभाषाएं वस्तुओं से संबंधित हैं। इसलिए, मुझे एक ही स्थान पर सभी डेटा प्रकार परिभाषाएँ नहीं मिल सकती हैं। Erlang या C में, मैं अपने सभी डेटा प्रकारों को एक सम्मिलित फ़ाइल या डेटा शब्दकोश में परिभाषित कर सकता हूं। ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं में, मैं यह नहीं कर सकता - डेटा प्रकार की परिभाषाएँ सर्वव्यापी हैं।

मैं एक उदाहरण दूंगा। मान लीजिए मैं एक विश्व स्तर पर दृश्यमान डेटा प्रकार को परिभाषित करना चाहता हूं।

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

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

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

आपत्ति संख्या ४। वस्तुओं में एक छिपी हुई अवस्था होती है।

हालत सभी समस्याओं की आधारशिला है। विशेष रूप से - दुष्प्रभावों के साथ कार्यों से बचने के लिए आवश्यक है।

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

प्रोग्रामिंग भाषा वास्तविक दुनिया से इस राज्य के साथ काम करने की पेशकश क्या कर सकती है?

• ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग लैंग्वेज कहेंगी "- आपको प्रोग्रामर से राज्य को छिपाने की आवश्यकता है।" राज्य छिपे हुए हैं, उन तक पहुंच केवल विशेष कार्यों का उपयोग करके प्राप्त की जा सकती है;
• पारंपरिक प्रोग्रामिंग भाषाएं (सी, पास्कल) कहेगी कि राज्य के चर की दृश्यता को भाषा के दायरे के नियमों द्वारा नियंत्रित किया जाना चाहिए;
• घोषणात्मक भाषाएँ कहेगी कि राज्य नहीं है।

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

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग लैंग्वेज के लिए चुना गया "प्रोग्रामर से छिपाएं" दृष्टिकोण सबसे खराब दृष्टिकोण है। राज्य को खोलने और कोड पर इसके प्रभाव को कम करने के बजाय, यह इस तरह छिपा रहा है जैसे कि यह असंगत है।

OOP इतना लोकप्रिय क्यों है?

• कारण 1 - हर कोई सोचता है कि यह सीखना आसान है;
• कारण 2 - हर कोई सोचता है कि इसका उपयोग कोड पुन: उपयोग की डिग्री बढ़ाने के लिए किया जा सकता है;
• कारण 3 - OOP के आसपास HYIP;
• कारण 4 - यह एक नया प्रोग्रामिंग उद्योग बनाता है।

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

यह वही है जो वास्तव में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को चलाता है।

अनुवादक से।
मूल: जो आर्मस्ट्रांग, यहाँ से लिया गया ।

एरलांग के लेखक जो आर्मस्ट्रांग द्वारा लिखित कुछ पुरातात्विक और प्रोग्रामर सर्कल पाठ में सनसनीखेज। पाठ लिखने की तिथि को विश्वसनीय रूप से स्थापित करना संभव नहीं था, लेकिन अप्रत्यक्ष डेटा को देखते हुए, यह 90 के दशक की शुरुआत में था।