OOP में दस चीजें मैं बर्दाश्त नहीं कर सकता

भगवान, कई बार मुझे सिर्फ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग से नफरत है ।

मुझे लगता है कि मैं अकेला नहीं हूं। एद्जर दिक्जस्त्र के अमर शब्द पढ़े:

"ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग एक बहुत बुरा विचार है जो केवल कैलिफ़ोर्निया के साथ आ सकता है।"

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

1. प्रतिमान

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग का प्रतिमान क्या है? क्या इसका सीधा जवाब है? मैंने इतने अलग-अलग संस्करण सुने हैं कि मैं खुद अब नहीं जानता।

यदि हम स्मॉलटाक के विचारों को देखते हैं, तो हम मंत्र के पार आएंगे: "सब कुछ एक वस्तु है।" चरों के अलावा। और पैकेज। और आदिम। संख्याएं और कक्षाएं भी काफी वस्तुएं नहीं हैं, और इसी तरह। जाहिर है, "सब कुछ एक वस्तु है" एक प्रतिमान का आधार नहीं हो सकता।

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

अन्य लोगों का कहना है कि OOP इनकैप्सुलेशन, एब्स्ट्रैक्शन और डेटा छिपा रहा है । सच है, अलग-अलग स्रोत आपको बताएंगे कि ये एक ही विचार का वर्णन करने के लिए सिर्फ अलग-अलग शब्द हैं। और अन्य लोग कहेंगे कि ये तीन मूलभूत रूप से भिन्न अवधारणाएँ हैं।

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

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

2. ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग लैंग्वेज

मैं भी उस तरह से नहीं करता जिस तरह से हर कोई दूसरी भाषाओं को नापसंद करना पसंद करता है। हम दुनिया को शिविरों में विभाजित करना पसंद करते हैं: ब्रेसिज़ बनाम स्क्वायर बनाम राउंड।

यहाँ कुछ चीजें हैं जो हमारे प्यारे NWFS के बारे में कही गई थीं:

“सी पैर में अपने आप को गोली मारना आसान बनाता है; C ++ के साथ, यह करना कठिन है, लेकिन जब आप ऐसा करते हैं, तो आप अपने पूरे पैर को गोली मार देते हैं। "

यह ब्योर्न स्ट्रैज़प द्वारा कहा गया था, इसलिए सब कुछ ठीक है।

"मैंने 'ऑब्जेक्ट ओरिएंटेड' शब्द गढ़ा है, और यहाँ मैं आपको जो बताता हूँ: मैंने C ++ का मतलब नहीं समझा।" - आलिया के।

"सी ++ में, केवल 2 चीजें गलत हो गईं: प्रारंभिक डिजाइन और कार्यान्वयन।" - बर्ट्रेंड मेयर

"अंदर सी ++ एक और अधिक कॉम्पैक्ट और समझने योग्य भाषा बैठता है, जिससे बाहर निकलने की पूरी कोशिश होती है।" - ब्योर्न स्ट्रैज़ुप

“सी ++ एक कहानी है जो खुद को एक त्रासदी के रूप में दोहरा रही है। जावा एक कहानी है जो खुद को बहुत दोहराती है। ” - स्कॉट मैके

"जावा, C ++ के बाद स्मॉलटॉक के लिए सबसे अच्छा तर्क।" - फ्रैंक विंकलर

"अगर जावा में एक वास्तविक कचरा संग्रहकर्ता होता, तो अधिकांश कार्यक्रम खुद को रनटाइम पर हटा देते।" - रॉबर्ट सीवेल

और शायद सबसे व्यापक वाक्य:

"केवल 2 प्रकार की भाषाएं हैं: उन लोगों के बारे में जो हर कोई शिकायत करता है और कोई भी उपयोग नहीं करता है।" - ब्योर्न स्ट्रैज़प

3. कक्षाएं

कक्षाएं मुझे पागल कर देती हैं। यह अजीब लग सकता है, इसलिए मुझे समझाएं।

कक्षाएं सुविधाजनक लगती हैं। हमारा मस्तिष्क हमारे आसपास की दुनिया से प्राप्त जानकारी को पूरी तरह से वर्गीकृत करता है। और वस्तु-उन्मुख कार्यक्रमों में सब कुछ वर्गीकृत करना स्वाभाविक होगा।

हालांकि, वास्तविक दुनिया में केवल वस्तुएं हैं। कक्षाएं हमारे दिमाग में ही मौजूद हैं। क्या आप वास्तविक दुनिया से कम से कम एक उदाहरण दे सकते हैं कि एक वर्ग एक वास्तविक, भौतिक इकाई है? नहीं, मुझे ऐसा नहीं लगता।

और यहाँ समस्या है। क्या आपने कभी सोचा है कि एक वस्तु-उन्मुख भाषा में एक कार्यक्रम एक प्रक्रियात्मक से समझने के लिए इतना अधिक कठिन क्यों है?

प्रक्रियात्मक कार्यक्रमों में, प्रक्रियाएं अन्य प्रक्रियाओं को बुलाती हैं। प्रक्रियात्मक कोड दिखाता है ... ऐसी प्रक्रियाएं जो अन्य प्रक्रियाओं को लागू करती हैं। सब कुछ ठीक और सरल है, है ना?

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

मुझे लगता है कि स्मॉलटॉकर्स को डिबगर में प्रोग्राम करना क्यों पसंद है: बाद वाला उन्हें निष्पादन योग्य वस्तुओं पर नियंत्रण हासिल करने की अनुमति देता है और उन्हें सीधे प्रोग्राम करने की अनुमति देता है।

यहाँ मैं टूल डेवलपर्स से क्या कहना चाहूंगा: कृपया हमें एक आईडीई दें जो कक्षाओं के बजाय ऑब्जेक्ट दिखाएगा!

4. तरीके

ईमानदारी से, मुझे भी तरीकों से नफरत है।

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

इस बात पर विचार करें कि हम ऑब्जेक्ट-ओरिएंटेड कोड को लिखने से ज्यादा समय पढ़ने में बिताते हैं। इसे प्रदर्शन कहा जाता है: नई कार्यक्षमता जोड़ने के लिए घंटों तक बड़ी मात्रा में कोड लिखने के बजाय, हम केवल कुछ लाइनें लिखते हैं, लेकिन साथ ही यह पता लगाने की कोशिश करते हैं कि आपको किन लाइनों को लिखने की आवश्यकता है!

जिन कारणों से हम इतना समय बिताते हैं उनमें से एक यह है कि हमें कोड को छोटे-छोटे तरीकों से आगे-पीछे करना होगा।

इसे स्पेस लॉस्ट सिंड्रोम के रूप में भी जाना जाता है और पीएलओ के निर्माण के बाद से इसके बारे में बात की जाती है। एडेल गोल्डबर्ग को उद्धृत करते हुए, "स्मॉलटॉक में, सब कुछ कहीं और होता है।"

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

और बात खुद OOP नहीं है - हम अभी तक समझ नहीं पाए हैं (40 से अधिक वर्षों के बाद) इसके लिए कार्यक्रम कैसे विकसित करें। हमें खुद से पूछना चाहिए: आईडीई में स्रोत कोड प्रमुख मानचित्रण क्यों रहता है?

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

5. प्रकार

ठीक है, मैं मानता हूं: मैं अधीर हूं और दो बार दोहराए जाने वाले शब्दों से नफरत करता हूं। प्रकार मुझे बनाते हैं।

अब किसी ने शायद सोचा: “लेकिन आप एक टाइपिंग भाषा में कैसे लिख सकते हैं। आपको कभी भी यकीन नहीं होगा कि आपका कोड सही है। ”

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

समस्या स्वयं प्रकारों के साथ है, जैसा कि हम उन्हें जानते हैं। सबसे पहले, वे झूठी सुरक्षा की भावना को जन्म देते हैं। यह तथ्य कि आपका जावा प्रोग्राम संकलित है, इसका मतलब यह नहीं है कि इसमें त्रुटियाँ नहीं हैं (और प्रकार के साथ त्रुटियां भी)।

दूसरे और मुख्य रूप से, टाइपिंग मानती है कि दुनिया स्थिर है, और इसमें प्रोग्राम निरंतर भागों से मिलकर होते हैं, लेकिन ऐसा नहीं है । इस वजह से, कुछ उपयोगी प्रकार के कार्यक्रम (विशेष रूप से चिंतनशील) लिखना कठिन हो जाता है।

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

6. भिन्नता

"परिवर्तन अपरिहार्य है - एक वेंडिंग मशीन से छोटी चीजों के विपरीत।" - रॉबर्ट गैलागर

हम सभी को बदलना पसंद नहीं है, है ना? और यदि ऐसा है, तो अगर चीजें बेहतर नहीं होती हैं तो शिकायत क्यों करें? हम जानते हैं कि उपयोगी कार्यक्रमों को बदलना होगा, या वे समय के साथ खराब हो जाएंगे।

(वैसे, क्या आप जानते हैं कि हार्डवेयर और सॉफ्टवेयर में क्या अंतर है? यदि आप इसे काम करने की स्थिति में नहीं रखते हैं तो हार्डवेयर खराब हो जाता है।)

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

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

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

7. डिजाइन पैटर्न

पैटर्न। मैं उनके साथ नहीं रह सकता, मैं उनके बिना नहीं रह सकता।

प्रत्येक डिज़ाइन पैटर्न आपके प्रोजेक्ट को अधिक भ्रमित करता है।

मैंने सब कुछ कह दिया है।

8. तरीके

"सभी कार्यप्रणाली भय पर आधारित हैं।" - केंट बैक

मेरे कुछ छात्र चक नॉरिस की शैली में चुस्त कार्यप्रणाली पर काम करते दिख रहे हैं:

“चक नॉरिस पुनरावृत्त नहीं है। सब कुछ पहली बार, हर बार होता है। ”

"चक नॉरिस प्रलेखन नहीं लिख रहा है। वह तब तक कोड को देखता है जब तक कि वह सब कुछ नहीं कहता जो आपको जानना चाहिए। ”

9. यूएमएल

बर्ट्रेंड मेयर इस बारे में बात करते हैं कि वह कैसे आश्चर्यचकित थे कि योजनाबद्ध प्रोग्रामिंग भाषाएं हमेशा इतनी लोकप्रिय क्यों थीं जब तक कि एक दिन यह उस पर नहीं पड़ा: "बुलबुले टूटते नहीं हैं!" (मेयर का एक और बयान: "आपको बस कोड की आवश्यकता है" )

ऐसा लगता है कि आमतौर पर मॉडलिंग के माध्यम से विकास को क्या समझा जाता है, कुछ गलत भी है: मॉडल से कोई कोड उत्पन्न नहीं होना चाहिए - मॉडल कोड होना चाहिए ।

संयोग से, फोरट्रान को एक उच्च-स्तरीय भाषा के रूप में विपणन किया गया था, जहां से स्रोत कोड उत्पन्न किया गया था। और अब हमारे लिए एक उच्च-स्तरीय भाषा स्रोत कोड है।

मुझे उम्मीद है कि एक दिन जब हम बड़े हो जाएंगे, तो मॉडल को स्रोत कोड माना जाएगा।

10. एक और नई बात

और अंत में, कैचफ्रेज़ जिसे मैं नफरत करता हूं: “ऑब्जेक्ट्स पर्याप्त नहीं हैं। और चाहिए… ” । इन सभी वर्षों में, हमें रूपरेखा, घटकों, पहलुओं, सेवाओं की आवश्यकता थी (जो, ऐसा लगता है, उत्सुकता से हमें प्रक्रियात्मक प्रोग्रामिंग पर वापस लौटा दिया गया है!)

यदि वस्तुएं कभी भी पर्याप्त नहीं थीं, तो इन सभी वर्षों में उन्होंने नियमित रूप से हमारी सेवा क्यों की?

निष्कर्ष?

25 साल पहले, हम इतने लंबे समय तक "नई" ओओपी घटना की उम्मीद नहीं करते थे।
हमने सोचा था कि OO सम्मेलन जैसे कि ECOOP , OOPSLA 5 साल तक चलेगा, और फिर मुख्यधारा में खो जाएगा।

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

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

आगे बढ़ने के लिए, हमें परिवर्तनशीलता पर ध्यान देने की आवश्यकता है और कैसे OOP परिवर्तनशीलता में योगदान कर सकता है। इतने सालों के बाद, हम अभी भी बहुत शुरुआत में हैं, यह समझने की कोशिश कर रहे हैं कि पीएलओ हमें क्या पेशकश कर सकता है।

पढ़ने के लिए धन्यवाद!

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

अनुसंधान OOP समुदाय में एक सक्रिय भागीदार, प्रतिभागी और ECOOP , ESEC और मॉडल जैसे सम्मेलनों के अध्यक्ष। (यह लेख केवल ECOOP 2010 में ऑस्कर का भाषण है)। द जर्नल ऑफ़ ऑब्जेक्ट टेक्नोलॉजी के प्रधान संपादक भी।

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