उद्देश्य-सी असीमित संचार: लक्ष्य/कार्य या प्रतिनिधिमंडल पैटर्न?

Question

मैं कुछ एसिंक्रोनस संचार परिस्थितियों से निपट रहा हूं (इवेंट-संचालित एक्सएमएल पार्सिंग, एनएसआरएल कनेक्शन कनेक्शन प्रोसेसिंग इत्यादि)। मैं अपनी समस्या को संक्षिप्त रूप से समझाने की कोशिश करूंगा:

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

मैं चीजों को इस तरह का लागू करने के लिए पैटर्न या अंगूठे का नियम एक तरह का पता लगाने के लिए मैं 3 संभव समाधान को देखने के कोशिश कर रहा हूँ और:

1. प्रतिनिधिमंडल पैटर्न: ग्राहक सेवा प्रदाता की है प्रतिनिधि और कार्य पूरा होने पर परिणाम प्राप्त होंगे।

2. लक्ष्य/क्रिया दृष्टिकोण का उपयोग करें: क्लाइंट सेवा प्रदाता से कार्य करने के लिए कहता है और एक चयनकर्ता को पास करता है जिसे कार्य पूरा करने के बाद सेवा प्रदाता द्वारा बुलाया जाना होगा।

3. नोटिफिकेशन का उपयोग करें।

(अद्यतन) समाधान # 2 (लक्ष्य और क्रिया) का प्रयास करने के कुछ समय बाद, मैं निष्कर्ष पर आया कि, मेरे मामले में, प्रतिनिधिमंडल दृष्टिकोण (# 1) का उपयोग करना बेहतर है। यहां प्रो और प्रत्येक विकल्प के विपक्ष कर रहे हैं, के रूप में मैं उन्हें देख:

प्रतिनिधिमंडल दृष्टिकोण:

• 1 (+) विकल्प 1 का उल्टा यह है कि हम यह कर सकते हैं संकलन के लिए चेक समय त्रुटियों क्योंकि ग्राहक सेवा प्रदाता के प्रतिनिधि प्रोटोकॉल को लागू करना होगा।

• 1 (-) यह भी नकारात्मक है क्योंकि यह क्लाइंट को सेवा प्रदाता के साथ कसकर जोड़ता है क्योंकि इसे अपने प्रतिनिधि प्रोटोकॉल को लागू करना है।

• 1 (+) यह प्रोग्रामर आसानी से कोड ब्राउज़ करें और ग्राहक की क्या विधि, सेवा प्रदाता अपने परिणामों पारित करने के लिए लागू किया जाता है पता लगाने के लिए अनुमति देता है।

• 1 (-) क्लाइंट प्वाइंट व्यू से, यह खोजना आसान नहीं है कि सेवा प्रदाता द्वारा परिणाम के बाद कौन सी विधि लागू की जाएगी। यह अभी भी आसान है, बस प्रतिनिधि प्रोटोकॉल विधियों पर जाएं और यही वह है, लेकिन # 2 दृष्टिकोण अधिक प्रत्यक्ष है।

• 1 (-) हमें अधिक कोड लिखना है: प्रतिनिधि प्रोटोकॉल को परिभाषित करें और इसे कार्यान्वित करें।

• 1 (-) इसके अलावा, प्रतिनिधिमंडल पैटर्न का व्यवहार वास्तव में व्यवहार करने के लिए किया जाना चाहिए। यह परिदृश्य प्रतिनिधिमंडल का एक सटीक मामला नहीं होगा, अर्थात् बोल रहा है।

लड़ाई/लक्ष्य दृष्टिकोण

• 2 (+) विकल्प 2 का उल्टा यह है कि जब सेवा प्रदाता विधि बुलाया जा रहा है, @selector कॉलबैक कार्रवाई को निर्दिष्ट करना चाहिए भी निर्दिष्ट किया जा सकता है, इसलिए प्रोग्रामर सही जानता है कि परिणामों को संसाधित करने के लिए किस विधि को वापस बुलाया जाएगा।

• 2 (-) इसके विरोध में, यह पता लगाना मुश्किल है कि सेवा प्रदाता कोड ब्राउज़ करते समय क्लाइंट में कौन सी विधि वापस कॉल की जाएगी। प्रोग्रामर को सेवा आमंत्रण में जाना चाहिए और देखें कि किसके साथ @ चयनकर्ता पारित किया जा रहा है।

• 2 (+) यह एक अधिक गतिशील समाधान है, और भागों के बीच कम युग्मन का कारण बनता है।

• 2 (-) शायद सबसे महत्वपूर्ण बातों में से एक: यह कर सकते हैं के रूप में ग्राहक एक चयनकर्ता कि सेवा प्रदाता के लिए मौजूद नहीं है पारित कर सकते हैं, रन-टाइम त्रुटियों और साइड इफेक्ट कारण।

• 2 (-) सरल और मानक दृष्टिकोण (#performSelector का उपयोग करना: withArgument: withArgument :) सेवा प्रदाता केवल 2 तर्कों को पारित कर सकते हैं।

सूचनाएं:

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

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

क्या मुझे कुछ याद आ रही है? आप क्या सलाह देते हैं और क्यों?

धन्यवाद!

Answer 1

बहुत अच्छा सवाल है।

मुझे नहीं लगता कि मैं योग्य हूं, अभी तक (जैसा कि मैं एक नौसिखिया हूं), इस पर टिप्पणी करने के लिए कि कौन सा डिज़ाइन पैटर्न दूसरे की तुलना में बेहतर है। सूचनाएं - लेकिन सिर्फ इतना है कि नकारात्मक पक्ष यह है कि आप बिंदु 2 (क्रम अपवाद) में उल्लिखित

if([delegate respondsToSelector:callback]){ 
    //call to callback here 
} 

आशा है कि विकल्प

Answer 2

आप एक तीसरा विकल्प को याद किया था वजन में मदद करता है से बचा जा सकता उल्लेख करना चाहता था।

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

यह अच्छी ढीली युग्मन के लिए अनुमति देता है; कुछ निर्णय सिर्फ नीचे है कि आप पुश/पुल सिस्टम चाहते हैं या नहीं।

Answer 3

प्रतिनिधिमंडल दृष्टिकोण के लिए एक और नकारात्मक पक्ष: एक सेवा प्रदाता के पास केवल एक प्रतिनिधि हो सकता है। यदि आपका सेवा प्रदाता एक सिंगलटन है, और आपके पास एकाधिक ग्राहक हैं, तो यह पैटर्न काम नहीं करता है।

इससे मुझे एक्शन/लक्ष्य दृष्टिकोण के लिए जाना पड़ा। मेरा सेवा प्रदाता राज्य रखता है और कई ग्राहकों के बीच साझा किया जाता है।