ओओपी समझ का विकास

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

OOP मुख्य रूप से एक उपकरण है

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

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

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

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

कार्रवाई ने जो किया है उससे अधिक महत्वपूर्ण है

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

किसी वस्तु के विचारों की गणना करने का कार्य

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