ओओपी पर विचार

"C ++ में प्रोग्रामिंग की मूल बातें" के बारे में एक अन्य लेख ने मुझे यह सोचने के लिए प्रेरित किया कि कई प्रोग्रामर ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (OOP) के सार को नहीं समझते हैं।







विशेष रूप से, यह लेख दावा करता है कि

"++ , ++ . "







काफी समय पहले, मंचों में से एक पर, मैं एक अन्य प्रोग्रामर के तर्क पर आया था जो "सार्वभौमिक" वस्तुओं के लिए भंडारण की व्यवस्था करना चाहता था और इस बारे में बात करता था कि क्या कुर्सी एक वस्तु है।



इन दोनों लोगों को किसी तरह OOP के बारे में गलत समझा जाता है।



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



भ्रम अक्सर "अच्छी वस्तु" शब्द के कारण भी उत्पन्न होता है। इसके अलावा, "क्लास" और "ऑब्जेक्ट" की अवधारणाएं अक्सर मिश्रित होती हैं।



तो, एक सरल नियम जो यह समझना आसान बनाता है कि ओओपी कहां है और कहां नहीं।



हेडलाइट्स और बेल्ट



BEHAVIOR और अवधारणा



अधिक बड़े पैमाने पर, वस्तुओं का एक वर्ग (OOP की समझ में) का उपयोग किया जाता है यदि ...



... कुछ इकाई का एक व्यवहार होता है जो उस इकाई की आंतरिक स्थिति पर निर्भर करता है।



"इकाई के पास एक राज्य है" क्या है? चलिए इसका पता लगाते हैं।



एक इकाई उदाहरण का अपना डेटा सेट है - यह स्पष्ट है। एक नियमित रिकॉर्ड (संरचना) से क्या अंतर है?



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



अब यह स्पष्ट हो रहा है कि इकाई का "व्यवहार" क्या है। यह तब होता है जब एक इकाई राज्य की शुद्धता को बनाए रखते हुए किसी प्रकार की कार्यक्षमता को लागू करती है।



आइए कुछ सरल उदाहरण लेते हैं। एक उत्पाद है: नाम, इकाई मूल्य, स्टॉक शेष। क्या यह OOP ऑब्जेक्ट है?



आगे पढ़ने से पहले सोचें।



यदि आप इसकी विशेषताओं पर कोई प्रतिबंध नहीं लगाते हैं - नहीं। राज्य उत्पन्न नहीं होता है।

हम किसी भी मूल्य में प्रवेश कर सकते हैं। छिपाने के लिए कुछ भी नहीं है।



आइए प्रतिबंधों का परिचय दें - शेष ऋणात्मक नहीं हो सकता है, और मूल्य सकारात्मक होना चाहिए।



और अब?



क्या अब कोई बाहरी उपयोगकर्ता उत्पाद में डेटा को मनमाने ढंग से बदल सकता है? जाहिर है कि नहीं। हमारे उत्पाद का एक व्यवहार है - संतुलन में कमी का मतलब है "एक निश्चित मात्रा में सामान उठाएं" और आप शेष राशि से अधिक नहीं ले सकते।



ध्यान दें क्या हुआ? हमने प्रतिबंधों को पेश किया, अर्थात्, सार के गुणों की प्रकृति में कुछ समझ बनाई। और तुरंत वहाँ सार्थक व्यवहार दिखाई दिया - "माल लाने के लिए", "सामान लेने के लिए"।



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



पीएलओ में कक्षाओं की प्रकृति को वास्तविक दुनिया की वस्तुओं की प्रकृति से जोड़ने के लिए बल्कि एक बेतुका और संवेदनहीन उपक्रम है। सार की प्रकृति वास्तविक दुनिया द्वारा निर्धारित नहीं की जाएगी, लेकिन प्रणाली द्वारा और सार के वातावरण पर निर्भर करती है, इसके उपयोग पर, घटकों के परस्पर संबंध पर।



वह सब है। आप इसे एनकैप्सुलेशन कह सकते हैं। और आप कॉल नहीं कर सकते। आप लंबे समय तक विरासत के बारे में बात कर सकते हैं। या आप बस समझ सकते हैं कि "विरासत" एक वस्तु के व्यवहार को बढ़ाने का एक तरीका है।



मुख्य बात यह समझना है कि एक प्रोग्रामर को विकास की जटिलता को नियंत्रित करने के लिए ओओपी की आवश्यकता होती है। और "वास्तविक दुनिया की वस्तुओं को प्रतिबिंबित करने के लिए" नहीं।



युपीडी



ठीक है, चलो स्मार्ट शब्दों को फेंकना जारी रखें।



अमूर्तता और बहुरूपता सीधे OOP से संबंधित नहीं हैं। अजीब तरह से पर्याप्त है।



कोई भी प्रक्रिया या कार्य एक अमूर्तता है। किसी भी। यहाँ घोषणा है:



शून्य प्रकार (इंट * सरणी, इंट आकार);



यह कार्य एक अमूर्तता है। यह छँटाई को लागू करता है। संक्षेप में। हम नहीं जानते कि कैसे।

लेकिन आउटपुट एक क्रमबद्ध सरणी होगी। अमूर्तता है, लेकिन ओओपी कहां है? कोई OOP नहीं। कोई वस्तु नहीं, कोई वर्ग नहीं।



अब मैंने एक तरह का पॉइंटर घोषित किया है। और मैं उसे यह कार्य सौंप सकता हूं:



शून्य quick_sort (int * array, int size)



या ऐसे:



शून्य बुलबुला_शॉर्ट (इंट * सरणी, इंट आकार)।



एक बहुरूपता थी। फ़ंक्शन पॉइंटर समान रहता है। लेकिन अब, विभिन्न एल्गोरिदम एक ही फ़ंक्शन पॉइंटर के पीछे हैं।



OOP कहाँ है? OOP मौजूद नहीं है। क्योंकि यह C ++ भी नहीं है, यह C. है जिसमें कोई वर्ग नहीं हैं। और अमूर्तता और बहुरूपता प्राप्त की जाती है।



हाँ?



UPD2



: - ;)



C, , this , , , this. ?



python, , ( ) - ?









यहाँ यह है। मैं इस बारे में बात कर रहा हूँ :-) मैंने कहीं भी एक पंक्ति नहीं लिखी है कि C ++ जरूरी OOP है। और बाकी माना जाता है कि नहीं है।



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



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



मैं C ++ में "खराब" क्लास बना सकता हूं। जो समन्वित राज्य परिवर्तन के सिद्धांत का उल्लंघन करता है।



और मैं C या अजगर में "सही" OOP को लागू कर सकता हूं। या असेंबलर में भी। मैं संस्थाओं को उजागर करूंगा और उन्हें बाहर से अपना राज्य बदलने की अनुमति नहीं दूंगा।



मेरे लेख का मुख्य विचार संकलक सुविधाओं के बारे में नहीं है।



और उस स्थिति के बारे में जब ओओपी का उपयोग करने वाला एक प्रोग्रामर सोचता है - "मुझे यहां (या नहीं) एक वर्ग की आवश्यकता है।"



यदि व्यवहार के साथ एक राज्य है, तो इसकी आवश्यकता है, अन्यथा, इसकी आवश्यकता नहीं है।



वह अपने प्रोग्रामिंग टूल पर इसे कैसे लागू करेगा, यह मेरे लिए महत्वपूर्ण नहीं है।