🛕 🛬 🤳🏼 डेटा प्रसंग इंटरैक्शन (डीसीआई) - एक वस्तु-उन्मुख प्रतिमान का विकास 👩🏻‍💼 👴 🔽

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

ऊ लाभ

आइए उन समस्याओं की समीक्षा के साथ शुरू करें जहां पारंपरिक ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग ने इसके लायक साबित किया है।

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

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

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

OO नुकसान

OO ऑब्जेक्ट्स के इंटरैक्शन को प्रदर्शित करने में हार जाता है। यह दिखाने के लिए कि मेरा क्या मतलब है, आइए एक ही समूह के दो सिस्टम ऑपरेशन (दो उपयोग परिदृश्य) पर एक नज़र डालते हैं जो एक दूसरे के साथ बातचीत कर रहे हैं।

पहले उपयोग का मामला

चित्र चार वस्तुओं के एक दूसरे के साथ संचार करने वाली प्रणाली के संचालन को दर्शाता है।

दूसरा उपयोग मामला

और यहां एक और उपयोग परिदृश्य प्रस्तुत किया गया है, वस्तुओं के एक ही समूह का उपयोग करके एक और सिस्टम ऑपरेशन। लेकिन जैसा कि आप देख सकते हैं, वस्तुओं और संदेशों के बीच बातचीत का मॉडल पहले से ही अलग है।

कोड सिस्टम संचालन प्रदर्शित नहीं करता है

हमने Use Case 1 और Use Case 2 में व्यक्त किए गए दो सिस्टम ऑपरेशन देखे। हम उन्हें कोड में कैसे प्रदर्शित करते हैं? आदर्श मामले में, मैं एक फ़ाइल खोलने में सक्षम होना चाहूंगा और उपयोग किए जाने वाले मामले में वस्तुओं के इंटरैक्शन के मॉडल को समझना चाहूंगा। अगर मैं Use Case 1 पर काम कर रहा हूं, तो मैं Use Case 2 के बारे में कुछ नहीं जानना चाहता। इसे मैं कोड में उपयोग के मामलों का एक सफल प्रदर्शन मानता हूं।

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

स्रोत कोड! = रनटाइम

अंततः, हम अभी भी कोड लिखते हैं और सिस्टम संचालन को किसी तरह से प्रोग्राम करते हैं। हम यह कैसे करते हैं? हम उन्हें कई छोटे तरीकों में विभाजित करते हैं और उन्हें विभिन्न वस्तुओं के एक समूह में असाइन करते हैं।

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

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

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

बचाव के लिए डीसीआई!

DCI (डेटा, संदर्भ, इंटरैक्शन) इन समस्याओं को हल करने के लिए Trygve Reenskaug (MVC टेम्पलेट के लेखक) द्वारा बनाया गया एक प्रतिमान है।

पहला उपयोग मामला (DCI)

आइए डीसीआई शैली में व्यक्त पहले उपयोग के मामले पर एक नज़र डालें।

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

हम बातचीत कैसे करते हैं?

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

दूसरा उपयोग मामला (DCI)

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

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

यह बहुत सार लग सकता है, तो चलो रूबी उदाहरण कोड पर एक नज़र डालें।

कोड उदाहरण

यहाँ केवल डीसीआई के लिए हैलो वर्ल्ड का एक उदाहरण है। डीसीआई में रुचि रखने वाले सभी लोग एक खाते से दूसरे खाते में पैसे के हस्तांतरण के साथ शुरू होते हैं।

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

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

class Account def decrease_balance(amount); end def increase_balance(amount); end def balance; end def update_log(message, amount); end def self.find(id); end end

जैसा कि आप देख सकते हैं, यहां सभी तरीके स्थानीय और संदर्भ-स्वतंत्र हैं। खाते में पैसे ट्रांसफर करने के बारे में कुछ भी नहीं पता है। वह केवल संतुलन को फिर से भरने और उससे पैसे पढ़ने के लिए जिम्मेदार है। धन हस्तांतरण का तर्क इस संदर्भ में है:

 class TransferringMoney include Context def self.transfer source_account_id, destination_account_id, amount source = Account.find(source_account_id) destination = Account.find(destination_account_id) TransferringMoney.new(source, destination).transfer amount end attr_reader :source_account, :destination_account def initialize source_account, destination_account @source_account = source_account.extend SourceAccount @destination_account = destination_account.extend DestinationAccount end def transfer amount in_context do source_account.transfer_out amount end end ... end

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

अगला, मैं अपने निर्माता में खाता वस्तुओं को भूमिकाएँ सौंपता हूँ। मैं इन डेटा ऑब्जेक्ट्स को स्रोत खाता और प्राप्तकर्ता खाता होने के लिए प्रशिक्षित करता हूं।

अंत में, मैं transef_out विधि को स्रोत खाते पर कॉल करके इंटरैक्शन आरंभ करता हूं। इस उदाहरण में, संदर्भ केवल इंटरैक्शन की शुरुआत करता है, लेकिन कुछ जटिल मामलों में, यह अभिनेताओं का समन्वय भी कर सकता है।

अब आइए भूमिका कार्यान्वयन पर एक नज़र डालते हैं:

 class TransferringMoney include Context ... def transfer amount ... end module SourceAccount include ContextAccssor def transfer_out amount raise "Insufficient funds" if balance < amount decrease_balance amount context.destination_account.transfer_in amount update_log "Transferred out", amount end end module DestinationAccount include ContextAccssor def transfer_in amount increase_balance amount update_log "Transferred in", amount end end end

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

कुछ दिलचस्प बातों पर ध्यान दें:

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

प्रसंग और दोनों भूमिकाएँ:

 class TransferringMoney include Context def self.transfer source_account_id, destination_account_id, amount source = Account.find(source_account_id) destination = Account.find(destination_account_id) TransferringMoney.new(source, destination).transfer amount end attr_reader :source_account, :destination_account def initialize source_account, destination_account @source_account = source_account.extend SourceAccount @destination_account = destination_account.extend DestinationAccount end def transfer amount in_context do source_account.transfer_out amount end end module SourceAccount include ContextAccssor def transfer_out amount raise "Insufficient funds" if balance < amount decrease_balance amount context.destination_account.transfer_in amount update_log "Transferred out", amount end end module DestinationAccount include ContextAccssor def transfer_in amount increase_balance amount update_log "Transferred in", amount end end end

हमारे पास क्या है?

इलाके

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

फोकस

संदर्भ में केवल विधियाँ होती हैं जो निष्पादन स्क्रिप्ट का हिस्सा होती हैं जो इसका प्रतिनिधित्व करती हैं। इसलिए आपको दर्जनों या सैकड़ों तरीकों को स्कैन नहीं करना होगा, जिस समस्या का आप काम कर रहे हैं, उससे कोई लेना-देना नहीं है।

"सिस्टम क्या है" और "सिस्टम क्या करता है"

सभी डेटा ऑब्जेक्ट और उनके स्थानीय तरीके खुद को "एक प्रणाली क्या है" व्यक्त करते हैं। आमतौर पर, सिस्टम का यह हिस्सा अपरिवर्तित होता है। प्रसंग-संवेदनशील, तेज़-तर्रार व्यवहार "सिस्टम क्या करता है"। तेजी से बदलते भागों से अपरिवर्तित भागों को अलग करना स्थिर सॉफ़्टवेयर के निर्माण के लिए आवश्यक शर्तों में से एक है। और DCI यह पृथक्करण प्रदान करता है:

DCI में डेटा हमें ऑब्जेक्ट की सामग्री के बारे में सब कुछ दिखाता है और इसके पड़ोसियों के बारे में कुछ भी नहीं बताता है ("सिस्टम जैसी क्या है")
डीसीआई में संदर्भ हमें वस्तुओं के संपर्क के नेटवर्क और उनकी सामग्री के बारे में कुछ भी नहीं दिखाता है ("सिस्टम क्या करता है")

स्रोत कोड == रैंतिम

साथ ही, सोर्स कोड रनटाइम से मेल खाता है। रनटाइम हमें दिखाता है कि हमारे पास दो खाते हैं और हस्तांतरण राशि है। यदि आप संदर्भ खोलते हैं तो यह आपको दिखाई देगा।

स्पष्ट भूमिकाएँ

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

सूत्रों का कहना है

वास्तव में लेख ही:

डेटा संदर्भ इंटरेक्शन: ऑब्जेक्ट ओरिएंटेड प्रतिमान का विकास

यदि आप इस विचार में रुचि रखते हैं, तो मैं आपको निम्नलिखित संसाधनों को देखने की सलाह देता हूं:

यदि आप किताबें पढ़ना पसंद करते हैं, तो मैं आपको ये तीन पुस्तकें सुझा सकता हूं:

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

डेटा प्रसंग इंटरैक्शन (डीसीआई) - एक वस्तु-उन्मुख प्रतिमान का विकास