हमें ओओपी की आवश्यकता क्यों है और यह क्या है

सभी को नमस्कार।

हेब पर लेख का एक सप्ताह OOP के लिए समर्पित है। पिछले लेख ने मुझे बहुत सारी भावनाओं का कारण बनाया और दुर्भाग्य से, बहुत बुरी भावनाएँ। मुझे लेख पसंद नहीं आया। क्यों? क्योंकि यह OOP के उपयोग के बारे में कुछ नकारात्मक भावनाओं को बताता है। भावनाएं केवल इस तथ्य के कारण होती हैं कि एक व्यक्ति ओओपी की पूरी शक्ति को पूरी तरह से नहीं समझता है और हर किसी को यह विश्वास दिलाना चाहता है कि ओओपी बुराई है। सबसे दुखद बात यह है कि लोग भयानक तर्क सुनना और फेंकना शुरू कर देते हैं जिनका वास्तविकता से कोई लेना-देना नहीं है। मुझे लगता है कि इस तरह के लेख गोफ से अधिक छात्रों के लिए contraindicated हैं, जो मैं जल्द से जल्द दे दूंगा। :)

चलिए शुरू करते हैं।

OOP क्या है OOP OO प्रोग्रामिंग और डिज़ाइन है। एक के बिना दूसरा पूरी तरह से बेकार है। सॉफ्टवेयर उत्पादों के डिजाइन / प्रोग्रामिंग के लिए OOP द्वारा बनाया गया। मॉडलिंग की प्रक्रिया के लिए नहीं। प्रोटोकॉल डिजाइन के लिए नहीं, बल्कि सॉफ्टवेयर उत्पादों के लिए, उनके कार्यान्वयन के लिए। सिस्टम को सरल बनाने के लिए जो प्रोटोकॉल या व्यावसायिक प्रक्रिया या कुछ और को लागू करेगा।

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

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

ये उपकरण कैसे काम करते हैं? हाँ, यह धमाकेदार शलजम से आसान है, क्योंकि यह सब हमारे परिचित चीजों पर आधारित है। मुझे जीवन से सरल उदाहरण पसंद हैं:

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

इस उदाहरण में, अमूर्तता का स्तर अच्छी तरह से चुना गया है। सभी अपने व्यापार के बारे में जाते हैं, सभी तीन ओओपी व्हेल महिमा के लिए काम करते हैं। लेकिन अगर मैं एक बुरा अमूर्त चुनता हूं, तो एक वास्तविक दुःस्वप्न शुरू होता है। और यहां तक ​​कि cheklist मानक भी हैं जो आपको यह समझने में मदद करेंगे कि क्या आपने सार को अच्छी तरह से चुना है और क्या आपका विघटन उस दिशा में सही है, जिस दिशा में आप जा रहे हैं (SOLID)।

उन्होंने ओओपी के एक अन्य स्तंभ के रूप में, अमूर्तता को जोड़ना शुरू किया। मुझे लगता है कि यह अधिक संभावना सच है, लेकिन यह वास्तव में सीईपी की स्मैक है।

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

लेख में दिए गए शेष उदाहरण जो मुझे पकड़े गए, वे कार्य के ढांचे में संक्षिप्त रूप से चुने गए अमूर्त और सादृश्य के उदाहरण थे। बिंदु।

अलग से, डीटीओ के बारे में। DTO एक पैटर्न है। यह आपको एक ऐसी वस्तु बनाने की अनुमति देता है जो किसी अन्य परत को, किसी अन्य प्रणाली को, संक्षेप में, कहीं न कहीं यह कुछ संचारित करेगी। क्यों यह मेरे द्वारा एक वस्तु के रूप में नहीं माना जा सकता है आम तौर पर मेरे लिए एक रहस्य है। फिर विरोधाभास कहां है? क्या कंटेनर ही है? तो क्या ?? ऑब्जेक्ट मॉडल के ढांचे में यह वही वस्तु है जिसे मैंने अमूर्त स्तर पर जांच की थी, जहां डीटीओ वस्तु और अपघटन का हिस्सा है।

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

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

सारांश। यदि आप ओओपी की शक्ति को नहीं समझते हैं, तो सबसे अधिक संभावना है कि आपको ऑब्जेक्ट थिंकिंग विकसित करने की आवश्यकता है।

PS पिछले लेख की टिप्पणियों में, मैं स्पष्ट रूप से कुछ लोगों को संबोधित करते समय बहुत दूर चला गया। मैं माफी मांगता हूं।