ऑब्जेक्ट्स जो खुद को भेजते हैं - एक अच्छा विचार?

Question

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

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

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

Answer 1

वहाँ पेलोड स्वयं आइटम के साथ क्या करना तर्क है: अब क्या हवा की गति क्या है?

वहाँ है कि डेटा की व्याख्या के साथ क्या करना तर्क है: हम अब इस जहाज डॉक कर सकते हैं?

वहाँ पेलोड कहीं भेजने के लिए निर्णय लेने से से कोई लेना देना तर्क है: ओह यहाँ एक नया मौसम मूल्य है, someobody वहाँ पर ध्यान रखती है।

फिर वास्तविक नेटवर्क सामग्री।

पेलोड शायद क्रमानुसार और खुद deserialise करने में सक्षम होने की जरूरत है। मुझे नहीं लगता कि बाकी में से कोई भी पेलोड की चिंता है। भेजें() के लिए एक बेहतर जगह होना चाहिए। कम से कम नहीं क्योंकि आप एक बार में कई पेलोड ऑब्जेक्ट्स भेजना चुन सकते हैं, और वे सभी एक-दूसरे को नहीं भेज सकते हैं।

Answer 2

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

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

Answer 3

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

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

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

Answer 4

संक्षिप्त उत्तर यह है कि यह किस डाउनस्ट्रीम प्रभाव से निपटना चाहता है इस पर निर्भर करता है।

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

तो आपके द्वारा उठाए गए प्रश्न यह है कि जब कोई ऑब्जेक्ट अपने डेटा में हेरफेर कर सकता है और मुझे इसे अलग करने की आवश्यकता कब होती है।

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

दूसरी ओर यह एपीआई को उपयोग करने में कठोर बनाता है क्योंकि यह हमेशा स्पष्ट नहीं होता है कि सामान कहां है। इससे यह संभावना भी बन जाती है कि एक ही नीति कई स्थानों पर बनाई गई है (और प्रत्येक परत कुछ कैशिंग को कार्यान्वित करती है)

उदाहरण के लिए यदि स्ट्रिंग क्लास जैसे स्ट्रिंग और जॉइन और सबस्ट्रिंग स्ट्रिंग क्लासेस को ढूंढना आसान नहीं था और इसके बजाय जहां कहीं और उदाहरण के लिए एक काल्पनिक पार्स क्लास की संभावना है कि इससे पहले कि मुझे इस काल्पनिक पार्स क्लास को मिला, तो मैंने उन तरीकों के कई क्रैपी संस्करणों को लिखा होगा। इसका वास्तविक जीवन उदाहरण तब होता है जब लोगों ने गणित वर्ग के उन तरीकों के समान तरीके लिखे हैं क्योंकि उन्हें इसके बारे में पता नहीं है।

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

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