OOP के बारे में आम गलतफहमी

नमस्कार, हेब्र!

आज, एक अनुवादित प्रकाशन आपकी प्रतीक्षा करता है, कुछ हद तक OOP और FI पर नई पुस्तकों से संबंधित हमारी खोजों को दर्शाता है। कृपया मतदान में भाग लें।



क्या OOP प्रतिमान मृत है? क्या यह कहा जा सकता है कि कार्यात्मक प्रोग्रामिंग भविष्य है? ऐसा लगता है कि कई लेख इस बारे में लिखते हैं। मैं इस बात से असहमत हूं। बात करते हैं!

हर कुछ महीनों में मुझे कुछ ब्लॉग पर एक पोस्ट आता है, जहाँ लेखक ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए बहुत अच्छी तरह से दावा करता है, जिसके बाद वह OOP को अतीत का अवशेष घोषित करता है, और हम सभी को कार्यात्मक प्रोग्रामिंग पर स्विच करना पड़ता है।

इससे पहले, मैंने लिखा था कि OOP और FI एक-दूसरे का विरोध नहीं करते। इसके अलावा, मैं उन्हें बहुत सफलतापूर्वक संयोजित करने में सक्षम था।

इन लेखों के लेखकों को OOP के साथ इतनी समस्याएं क्यों हैं, और AF उन्हें ऐसा स्पष्ट विकल्प क्यों लगता है?

OOP कैसे सिखाये

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

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

विरासत

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

 class BlogController extends FrameworkAbstractController { } 

यह माना जाता है कि इस तरह से आपके लिए इस तरह से कॉल करना आसान हो जाएगा this.renderTemplate(...) , क्योंकि इस तरह के तरीकों को FrameworkAbstractController क्लास से विरासत में मिला है।

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

इसमें भ्रमित होने की कोई बात नहीं है। और अगर हमने रचना और निर्भरता इंजेक्शन के साथ दृष्टिकोण चुना, तो यह इस तरह से निकला होगा:

 class BlogController { public BlogController ( TemplateRenderer templateRenderer ) { } } 

आप देखते हैं, आप अब कुछ धूमिल FrameworkAbstractController पर निर्भर नहीं हैं, लेकिन एक बहुत अच्छी तरह से परिभाषित और संकीर्ण चीज़, TemplateRenderer पर निर्भर हैं। वास्तव में, BlogController किसी अन्य नियंत्रक से विरासत में नहीं BlogController है, क्योंकि यह किसी भी व्यवहार को विरासत में नहीं मिला है।

कैप्सूलीकरण

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

यह अवसर, फिर से, उपयोग और दुरुपयोग की अनुमति देता है। इस मामले में दुरुपयोग का मुख्य उदाहरण एक टपका हुआ राज्य है।

अपेक्षाकृत बोल, मान लें कि List<> वर्ग में तत्वों की एक सूची है, और इस सूची को बदला जा सकता है। चलिए एक आदेश टोकरी को संसाधित करने के लिए एक वर्ग बनाते हैं:

 class ShoppingCart { private List<ShoppingCartItem> items; public List<ShoppingCartItem> getItems() { return this.items; } } 

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

 shoppingCart.getItems().clear(); 

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

इस विशेष उदाहरण में, शॉपिंगकार्ट वर्ग के लेखक समस्या को दरकिनार करने के लिए अपरिवर्तनीयता का उपयोग कर सकते हैं और सुनिश्चित कर सकते हैं कि एनकैप्सुलेशन सिद्धांत का उल्लंघन नहीं किया गया है।

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

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

मतिहीनता

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

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

बहुरूपता

अंत में, बहुरूपता के बारे में बात करते हैं। उनका सुझाव है कि एक वर्ग कई व्यवहारों को लागू कर सकता है। एक खराब पाठ्यपुस्तक का उदाहरण यह लिखना है कि बहुरूपता के साथ Square या तो एक Rectangle या एक Parallelogram चतुर्भुज हो सकता है। जैसा कि मैंने पहले ही ऊपर बताया है, ओओपी में यह निश्चित रूप से असंभव है, क्योंकि इन संस्थाओं के व्यवहार अलग हैं।

बहुरूपता की बात करते हुए, किसी को कोड नहीं, बल्कि व्यवहार को ध्यान में रखना चाहिए। एक अच्छा उदाहरण कंप्यूटर गेम में Soldier क्लास है। यह Movable व्यवहार (स्थिति: यह स्थानांतरित हो सकता है) और Enemy व्यवहार (स्थिति: आपको गोली मारता है) दोनों को लागू कर सकता है। इसके विपरीत, GunEmplacement वर्ग केवल Enemy व्यवहार को लागू कर सकता है।

इसलिए, यदि आप Square implements Rectangle, Parallelogram लिखते हैं, तो यह कथन सत्य नहीं है। आपके तर्क व्यापार तर्क के अनुसार काम करना चाहिए। आपको कोड के बारे में व्यवहार के बारे में अधिक सोचना चाहिए।

एफपी चांदी की गोली क्यों नहीं है

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

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

इसके अलावा, अधिकांश कार्यों के दुष्प्रभाव नहीं होने चाहिए। दूसरे शब्दों में, उन्हें पृष्ठभूमि में किसी भी अप्रत्याशित स्थान पर डेटा नहीं बदलना चाहिए, लेकिन केवल इनपुट मापदंडों के साथ काम करना और आउटपुट का उत्पादन करना चाहिए।

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

समस्याएं तब शुरू होती हैं जब कुछ कार्यों को दूसरों पर निर्भर होना चाहिए। जब फ़ंक्शन A कॉल फ़ंक्शन B करता है, और फ़ंक्शन B एक और पाँच से छह फ़ंक्शन कॉल करता है, और बहुत अंत में एक शून्य-भरने वाला फ़ंक्शन पाया जाता है जो टूट सकता है - यह वह जगह है जहां आप ईर्ष्या नहीं करेंगे।

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

OOP या FP?

OOP और FI उपकरण हैं । अंततः, यह कोई फर्क नहीं पड़ता कि आप किस प्रोग्रामिंग प्रतिमान का उपयोग करते हैं। इस विषय पर अधिकांश लेखों में वर्णित समस्याएं कोड संगठन से संबंधित हैं।

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

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