ऑब्जेक्ट बनाम डेटा स्ट्रक्चर्स

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

कक्षा क्या है?

एक वर्ग कई समान वस्तुओं का एक विनिर्देश है।

वस्तु क्या है?

एक ऑब्जेक्ट फ़ंक्शंस का एक सेट होता है, जो एनकैप्सुलेटेड डेटा के साथ एक्शन करता है।

या यह कहना बेहतर है कि एक ऑब्जेक्ट फ़ंक्शंस का एक सेट है जो डेटा के साथ कार्य करता है जिसका अस्तित्व निहित है

"निहित" के अर्थ में?

एक बार ऑब्जेक्ट के कार्य होने के बाद, यह माना जा सकता है कि वहां भी डेटा है, लेकिन डेटा तक कोई सीधी पहुंच नहीं है और वे बाहर से बिल्कुल भी दिखाई नहीं देते हैं।

वस्तु में डेटा नहीं है?

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

अच्छा, चलिए बताते हैं।

खैर, एक डेटा संरचना क्या है?

डेटा संरचना संबंधित वस्तुओं का एक संग्रह है।

या, दूसरे शब्दों में, एक डेटा संरचना उन तत्वों का एक समूह है जिनके साथ कार्य करते हैं, जिनमें से अस्तित्व को निहित किया जाता है।

ठीक है, ठीक है। मुझे मिल गया। डेटा संरचनाओं के साथ काम करने वाले कार्य इन संरचनाओं के अंदर परिभाषित नहीं होते हैं, लेकिन डेटा संरचना के बहुत ही अस्तित्व से हम यह निष्कर्ष निकाल सकते हैं कि कुछ ऐसा होना चाहिए जो उनके साथ काम करता हो।

यह सही है। और इन दो परिभाषाओं के बारे में क्या?

एक अर्थ में, वे एक-दूसरे के विरोधी हैं।

दरअसल। वे एक दूसरे के पूरक हैं। एक हाथ और एक दस्ताने की तरह।

• एक ऑब्जेक्ट फ़ंक्शन का एक सेट है जो डेटा तत्वों के साथ काम करता है जिसका अस्तित्व अंतर्निहित रूप से निहित है।
• एक डेटा संरचना डेटा तत्वों का एक सेट है जिसके साथ काम करता है, जिसका अस्तित्व अंतर्निहित रूप से निहित है।

वाह! तो यह पता चला है कि वस्तुओं और डेटा संरचना एक ही बात नहीं है!

ठीक है। डेटा संरचनाएँ डीटीओ हैं।

और डेटाबेस में टेबल ऑब्जेक्ट्स या तो सही नहीं हैं?

फिर से सच डेटाबेस में डेटा स्ट्रक्चर होते हैं, न कि ऑब्जेक्ट।

एक पल रुकिए। डेटाबेस से ऑब्जेक्ट्स के लिए ORM मैप टेबल नहीं करता है?

बिल्कुल नहीं। आप ऑब्जेक्ट्स के लिए डेटाबेस टेबल मैप नहीं कर सकते। डेटाबेस में टेबल्स डेटा संरचनाएं हैं, न कि वस्तुएं।

फिर ORM क्या करते हैं?

वे एक संरचना से दूसरे में डेटा स्थानांतरित करते हैं।

इसलिए उनका वस्तुओं से कोई लेना-देना नहीं है?

कुछ भी नहीं। कड़ाई से बोलना, प्रौद्योगिकी के संदर्भ में ओआरएम के रूप में ऐसी चीज जो वस्तुओं से संबंधपरक डेटा को मैप करती है, मौजूद नहीं है, क्योंकि तालिकाओं को डेटाबेस से ऑब्जेक्ट में मैप नहीं किया जा सकता है।

लेकिन उन्होंने मुझे बताया कि ORM व्यापारिक वस्तुओं को इकट्ठा करते हैं।

नहीं, ORM उस डेटाबेस के डेटा को पुनः प्राप्त करता है, जिसके साथ व्यावसायिक वस्तुएँ काम करती हैं

लेकिन क्या ये डेटा संरचनाएं व्यावसायिक वस्तुओं में नहीं आती हैं?

शायद उन्हें मिलता है, या शायद नहीं। ORM को इस बारे में कुछ भी पता नहीं है।

लेकिन अंतर विशुद्ध रूप से शब्दार्थ है।

नहीं, नहीं। इसके दूरगामी परिणाम हैं।

उदाहरण के लिए?

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

Eeee। यह समझ से बाहर है।

इसके बारे में इस तरह से सोचें। डेटा योजना एक एकल अनुप्रयोग के लिए डिज़ाइन नहीं की गई है, यह पूरे उद्यम में उपयोग के लिए है। इसलिए, डेटा संरचना कई अलग-अलग अनुप्रयोगों के बीच एक समझौता है।

यह समझ में आता है।

सब ठीक है। अब हर एक एप्लीकेशन के बारे में सोचें। प्रत्येक एप्लिकेशन का ऑब्जेक्ट मॉडल बताता है कि आवेदन का व्यवहार कैसे संरचित है। एप्लिकेशन के व्यवहार से बेहतर मिलान करने के लिए प्रत्येक एप्लिकेशन का अपना ऑब्जेक्ट मॉडल होगा।

आह, मैं देख रहा हूँ। चूंकि डेटा योजना विभिन्न अनुप्रयोगों के बीच एक समझौता है, इसलिए यह योजना प्रत्येक व्यक्ति के आवेदन के ऑब्जेक्ट मॉडल पर नहीं आएगी।

यह सही है! ऑब्जेक्ट और स्ट्रक्चर्स अलग-अलग चीजों तक सीमित हैं। वे बहुत कम ही एक साथ फिट होते हैं। लोग इसे वस्तु-संबंधात्मक प्रतिबाधा का बेमेल विवाह कहते हैं।

कुछ मुझे याद है। लेकिन ऐसा लगता है कि प्रतिबाधा बेमेल को ORM का उपयोग करके ठीक किया गया था।

और अब आप जानते हैं कि ऐसा नहीं है। वस्तुओं और डेटा संरचनाओं के बीच प्रतिबाधा बेमेल पूरक है, आइसोमोर्फिक नहीं।

क्या?

वे विपरीत हैं, कुछ समान नहीं हैं।

विपरीत?

हाँ, एक बहुत ही दिलचस्प अर्थ में। आप देखते हैं, ऑब्जेक्ट्स और डेटा स्ट्रक्चर्स कंट्रोल स्ट्रक्चर्स स्ट्रक्चर का विरोध करते हैं।

क्या?

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

सभी उदाहरणों में वस्तुओं के साथ आकृतियों को कोड कितना अलग करते हैं?

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

कृपया धीमा करें, कुछ भी स्पष्ट नहीं है।

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

ठीक है। बेशक। एक वस्तु को पता है कि उसके तरीकों को कैसे लागू किया जाता है। स्वाभाविक रूप से।

अब इन वस्तुओं को डेटा संरचनाओं में बदलते हैं। हम भेदभाव रहित यूनियनों का उपयोग करते हैं।

भेदभाव क्या?

भेदभाव रहित संघ। खैर, C ++, पॉइंटर्स, यूनियन कीवर्ड, संरचना के प्रकार को निर्धारित करने के लिए एक ध्वज, भेदभाव रहित यूनियन। हमारे मामले में, ये सिर्फ दो अलग-अलग डेटा संरचनाएं हैं। एक स्क्वायर के लिए और एक सर्कल के लिए। सर्कल में एक केंद्र बिंदु और एक त्रिज्या है। और एक प्रकार कोड जिससे यह समझा जा सकता है कि यह एक सर्कल है।

कोड के साथ क्षेत्र enum होगा?

अच्छा, हाँ। और स्क्वायर में ऊपरी बाएं बिंदु और साइड की लंबाई होगी। और प्रकार को इंगित करने के लिए भी enum।

ठीक है। एक प्रकार कोड के साथ दो संरचनाएं होंगी।

यह सही है। अब क्षेत्र के लिए फ़ंक्शन देखें। शायद एक स्विच होगा, है ना?

खैर। बेशक, दो वर्गों के लिए। स्क्वायर और सर्कल के लिए शाखा। और परिधि के लिए, आपको एक समान स्विच की भी आवश्यकता है।

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

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

आगे बेहतर है। वस्तुओं के मामले में, यदि आपको त्रिभुज प्रकार जोड़ने की आवश्यकता है, तो किस कोड को बदलना चाहिए?

कुछ भी मत बदलो। बस एक नया त्रिभुज वर्ग बनाएं। हालांकि नहीं, आपको संभवतः उन कोड को ठीक करने की आवश्यकता है जो ऑब्जेक्ट बनाता है।

यह सही है। इसलिए, नए प्रकार को जोड़ते समय, परिवर्तन नगण्य हैं। अब मान लें कि आपको एक नया फ़ंक्शन जोड़ने की आवश्यकता है - उदाहरण के लिए, केंद्र को निर्धारित करने के लिए एक फ़ंक्शन।

फिर आपको इसे तीनों प्रकारों, सर्कल, स्क्वायर और त्रिभुज में जोड़ना होगा।

सब ठीक है। यह पता चला है कि नए कार्यों को जोड़ना मुश्किल है, क्योंकि आपको प्रत्येक वर्ग में बदलाव करना होगा।

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

यह सही है। प्रकार जोड़ना मुश्किल है, आपको प्रत्येक फ़ंक्शन को संपादित करना होगा।

लेकिन केंद्र के लिए एक फ़ंक्शन जोड़ने के लिए, कुछ भी बदलने की आवश्यकता नहीं है।

हाँ। सुविधाएँ जोड़ना आसान है।

वाह। यह पता चला है कि ये दोनों दृष्टिकोण सीधे विपरीत हैं।

निश्चित रूप से हाँ। संक्षेप में देना

• कक्षाओं में नए कार्यों को जोड़ना मुश्किल है, आपको प्रत्येक कक्षा में परिवर्तन करना होगा
• डेटा संरचनाओं में नए कार्यों को जोड़ना सरल है, आपको बस एक फ़ंक्शन जोड़ने की आवश्यकता है, और कुछ नहीं बदलना होगा
• नए प्रकार को कक्षाओं में जोड़ना सरल है, आपको बस एक नया वर्ग जोड़ने की आवश्यकता है
• संरचनाओं के लिए नए प्रकार जोड़ना मुश्किल है, आपको प्रत्येक फ़ंक्शन को ठीक करने की आवश्यकता है

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

अच्छा अवलोकन! लेकिन आज हमें एक बात और सोचने की जरूरत है। एक और बिंदु है जिसमें डेटा संरचनाएं और कक्षाएं एक दूसरे के विपरीत हैं। निर्भरता।

लत?

हाँ, स्रोत कोड में निर्भरता की दिशा।

ठीक है, मैं पूछूंगा। अंतर क्या है?

आइए संरचनाओं के मामले को देखें। प्रत्येक फ़ंक्शन में एक स्विच होता है जो यूनियन में टाइप कोड के आधार पर वांछित कार्यान्वयन का चयन करता है।

हाँ, यह है। तो क्या?

आइए क्षेत्र के लिए फ़ंक्शन कॉल देखें। कॉलिंग कोड क्षेत्र के लिए फ़ंक्शन पर निर्भर करता है, और क्षेत्र के लिए फ़ंक्शन प्रत्येक विशिष्ट कार्यान्वयन पर निर्भर करता है।

और जब आप कहते हैं कि "निर्भर" का क्या मतलब है?

कल्पना करें कि एक क्षेत्र के लिए एक फ़ंक्शन का प्रत्येक कार्यान्वयन एक अलग फ़ंक्शन को आवंटित किया गया है। यही है, इसमें सर्कलएरिया, स्क्वायरएरिया और ट्राइएंगल एरीए फ़ंक्शन होंगे।

खैर, यह पता चला है कि स्विच शाखाओं में बस इन कार्यों के लिए कॉल होंगे।

कल्पना कीजिए कि ये कार्य विभिन्न फाइलों में हैं।

फिर स्विच के साथ फाइल में आयात या उपयोग या फ़ंक्शन के साथ फ़ाइलों के लिए शामिल किया जाएगा।

वास्तव में। यह स्रोत कोड स्तर पर निर्भरता है। एक स्रोत दूसरे स्रोत पर निर्भर करता है। यह निर्भरता कैसे निर्देशित है?

स्विच के साथ स्रोत कोड उस स्रोत कोड पर निर्भर करता है जिसमें कार्यान्वयन स्थित हैं।

क्षेत्र के लिए फ़ंक्शन को कॉल करने वाले कोड के बारे में क्या?

कॉलिंग कोड स्विच के साथ कोड पर निर्भर करता है, जो सभी कार्यान्वयन पर निर्भर करता है।

ठीक है। सभी स्रोतों में, कॉलिंग की दिशा में, कॉलिंग कोड से कार्यान्वयन तक दिशा-निर्देश दिया गया है। तो अगर आप इन कार्यान्वयनों में एक छोटा बदलाव करना चाहते हैं ...

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

हां। कम से कम यह भाषाओं के लिए तो ऐसा होगा जो यह समझने के लिए फ़ाइल संशोधन तिथियों का उपयोग करें कि उन्हें फिर से बनाने की आवश्यकता क्या है।

और ये आम तौर पर स्थैतिक टाइपिंग के साथ सभी सिस्टम हैं, है ना?

हाँ, और इसके बिना कुछ अन्य प्रणालियाँ

इसके लिए बहुत पुनर्निर्माण करना होगा।

और इसे फिर से करने के लिए बहुत कुछ।

ठीक है, लेकिन कक्षाओं के मामले में क्या यह दूसरा तरीका है?

हां, क्योंकि क्षेत्र के लिए फ़ंक्शन को कॉल करने वाला कोड इंटरफ़ेस पर निर्भर करता है, और कार्यान्वयन भी इस इंटरफ़ेस पर निर्भर करता है।

मैं देखता हूं। स्क्वायर वर्ग के लिए कोड आकृति इंटरफ़ेस के साथ एक फ़ाइल को आयात या उपयोग करेगा या इसमें एक फ़ाइल शामिल होगी।

ठीक है। कार्यान्वयन फ़ाइलों में तीर कॉल के विपरीत दिशा में इंगित करता है। इसे कार्यान्वयन कोड से कॉल कोड तक निर्देशित किया जाता है। कम से कम यह सांख्यिकीय रूप से टाइप की जाने वाली भाषाओं के लिए मामला होगा। गतिशील रूप से टाइप की गई भाषाओं के लिए, क्षेत्र के लिए फ़ंक्शन को कॉल करने वाला कोड किसी भी चीज़ पर निर्भर नहीं करता है, क्योंकि रनटाइम में लिंकिंग होती है।

हाँ, ठीक है। यदि आप किसी एक कार्यान्वयन में परिवर्तन करते हैं ...

इन परिवर्तनों के साथ कोड को फिर से बनाना और फिर से स्थापित करना आवश्यक है।

ऐसा इसलिए है क्योंकि निर्भरता को कॉल की दिशा के विपरीत निर्देशित किया जाता है।

हां, हम इसे निर्भरता को उलटा कहते हैं।

ठीक है, यह सब संक्षेप में बताएं। कक्षाएं और डेटा संरचना तीन इंद्रियों में एक दूसरे के विरोध में हैं।

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

हाँ, यह सही है। और यह हर डिजाइनर और सॉफ्टवेयर आर्किटेक्ट द्वारा ध्यान में रखा जाना चाहिए।