पीएलओ के बचाव में। उनके विरोधियों के 7 अटूट तर्क

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

और ओओपी के चारों ओर केवल तूफान ही शांत नहीं करते हैं। खुशी में उसके पास से कुछ चिल्लाते हैं, अन्य, इसके विपरीत, प्रकाश क्या है पर दोष ढूंढते हैं। और सच कहूं, तो यह मेरे लिए पूरी तरह से अक्षम है कि पूरी दुनिया ओओपी में एक साथ क्यों आए।

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

मैं सिर्फ तीसरे तत्व में लाना चाहता हूं। यह शांत, प्रचार और दुरुपयोग के बिना है, यह बताने के लिए कि ओओपी सभी बीमारियों से अमृत क्यों नहीं है, लेकिन पीपी, एएफ या पीएल की तरह, भी अस्तित्व का अधिकार है।

इसलिए, ओओपी की रक्षा में एक शांत लेख। इसमें, मैं पीएलओ के विरोधियों के मुख्य तर्कों पर विचार करने और उनकी विफलता को उचित ठहराने की कोशिश करूंगा।

1. ओओपी में मौजूद हर चीज लंबे समय से अन्य प्रतिमानों में है

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

वैसे, यह एक ही थीसिस (सब कुछ जो एन में है, एम में है, और के, और आर में, आदि) को निम्नानुसार तैयार किया जा सकता है: हथौड़ा में पहले से ही लोहा और लकड़ी शामिल हैं, हमें सरौता की भी आवश्यकता क्यों है? लेकिन ऐसा कोई नहीं कहेगा।

2. OOP उन पर डेटा और क्रियाओं को मिलाता है। यह बुरा है

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

3. इनहेरिटेंस प्रोग्राम को गुलाम बनाता है, बदलाव को मुश्किल बनाता है

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

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

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

4. एनकैप्सुलेशन का कोई मतलब नहीं है

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

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

लेकिन जब आपने कक्षा को बनाया और कॉन्फ़िगर किया है, तो यह आपके लिए पहले से ही वायलेट है कि यह वहां कैसे काम करता है - यह सिर्फ सही ढंग से काम करता है, लेकिन आपको अधिक के लिए इच्छा नहीं है। और इन सभी संरचनाओं को घेरना, आप सब कुछ स्मृति में नहीं रखते हैं। वे (कई बक्से) बस एक दूसरे से बात करते हैं जिस तरह से आप सेट करते हैं।

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

हालांकि, यह शायद ही "अलस" आमतौर पर यहां उपयुक्त है।

5. वास्तविक दुनिया में कोई संबंध पदानुक्रम नहीं हैं, केवल हर जगह पदानुक्रम शामिल हैं

हाँ, वास्तव में? लेकिन कोई भी बनाने के लिए परेशान नहीं करता है, उदाहरण के लिए, एक पदानुक्रम जहां दुनिया की सभी नदियां (कांगो, सीन, टेम्स, अमेज़ॅन, कोलिमा, आदि) एक व्यापक "नदी" की वस्तुएं हैं, जिनमें अंतर्निहित गुण हैं (उदाहरण के लिए, पानी के होते हैं) और क्रियाएं (उदाहरण के लिए, बहती हैं), और पहले से ही यह "तालाब" से विरासत में मिली होगी, जिसमें पानी भी शामिल है, और "तालाब" से आप "झील" भी प्राप्त कर सकते हैं, जिसकी वस्तुएं अलग-अलग झीलें (बावल, कैस्पियन सागर, टिटिकाका, आदि) होंगी। .D।)। यह योजना बहुत कठिन है। लेकिन संबंध पदानुक्रम भी एक अमूर्तता है । यदि आप चाहते हैं कुछ एक ला प्लेटोनिक विचार, वास्तविक दुनिया में वे वहां नहीं हैं, वे केवल दिमाग में मौजूद हैं, यह एक सामान्यीकरण है, और इससे अधिक कुछ नहीं है। लेकिन यह ठीक है कि कोई व्यक्ति बहुत बार कैसे सोचता है। हम यह कह सकते हैं कि "जुर्राब" यह निर्दिष्ट किए बिना कि यह किस रंग का है, किस सामग्री से बुना जाता है, आदि, लेकिन क्या यह "जुर्राब" वास्तव में मौजूद है?

फिर भी, हमें शर्मिंदा नहीं होना चाहिए कि कोई "वस्तु" या "जुर्राब" नहीं है।

6. ओओपी कार्यप्रणाली शुरू में गलत है

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

7. लेकिन लाखों मक्खियाँ भी हमें यह नहीं समझाएंगी कि खाद स्वादिष्ट है।

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

---

यह आलेख पीएलओ के बचाव में क्यों है?

प्रोग्रामिंग प्रतिमानों के बारे में सभी आधुनिक बात करते हैं, जैसा कि मैं इसे देखता हूं, दो व्यास के परिसर में नीचे आता है: ओओपी छोड़ दें और बाकी को बाहर फेंक दें, या ओओपी को फेंक दें और ... ठीक है, आप मुझे समझते हैं।

मैं पूरी तरह से उपयुक्त प्रतिमान नहीं चाहता कि उसे एक योग्य डंप माना जाए, लेकिन मैं उसके चारों ओर गोल नृत्य नहीं करना चाहता, लेकिन बाकी सब कुछ भूल गया। मुझे लगता है कि दूसरा करना आसान है, लेकिन यह लेख पहले के खिलाफ निर्देशित है।

अगर आपको OOP पसंद नहीं है

किसको - OOP, किसको - FP, किसको - PP। और किसी को, शायद, सामान्य तौर पर, सुअर उपास्थि सभी मिठाई में से सबसे अधिक है। यदि आप बिल्लियों की तरह नहीं हैं, तो आप शायद उन्हें खाना बनाना नहीं जानते।