प्रतिनिधियों बनाम पर्यवेक्षक पैटर्न

Question

क्या आप पर कोई दिशा-निर्देश हैं जब आपको अप्रत्यक्ष सहयोगी और पर्यवेक्षक के लिए प्रतिनिधि का उपयोग करना चाहिए?

सी # में, आप सरल कॉल-बैक के लिए प्रतिनिधियों का उपयोग करते हैं। मुझे लगता है कि कार्यकर्ताओं को कार्य करने के लिए पॉइंटर्स और पॉइंटर्स को प्रतिनिधियों के रूप में भी माना जा सकता है (क्या मैं सही हूँ?)।

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

क्या प्रतिनिधि पर्यवेक्षक पैटर्न को म्यूट करते हैं? एक प्रतिनिधि बनाम एक पर्यवेक्षक पैटर्न पर आप कैसे निर्णय लेते हैं?

Answer 1

पर्यवेक्षक पैटर्न पहले से ही आपके लिए events के रूप में लागू किया गया है।

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

संपादित करें:As commenter Rabbi mentions, उपरोक्त पूरी तरह से सत्य नहीं है, क्योंकि कोई भी प्रतिनिधि बहुस्तरीय प्रतिनिधि बन सकता है। इवेंट संशोधक का उद्देश्य एक प्रतिनिधि बनाना है जिसे केवल कक्षा के अंदर ही बुलाया जा सकता है जो इसे परिभाषित करता है। यह सार्वजनिक इंटरफेस में encapsulation सुनिश्चित करने के लिए सबसे उपयोगी है।

Answer 2

पर्यवेक्षक पैटर्न को लागू करने के लिए प्रतिनिधियों का उपयोग किया जा सकता है - घटनाओं के बारे में सोचें।

यह ऐसा करने के लिए बिना ईवेंट यहां एक बार देख ले: http://www.dofactory.com/Patterns/PatternObserver.aspx

यह refactor करने के लिए है कि प्रतिनिधियों का उपयोग कर यदि आप पसंदीदा में ज्यादा नहीं ले जाएगा।

एकमात्र लाभ जो मैं इंटरफेस को लागू करने के बारे में सोच सकता हूं वह सभी कार्यान्वयन में सदस्य नाम स्थिरता है।

Answer 3

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

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