उद्देश्य-सी प्रतिनिधियों बनाम जावा श्रोताओं

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

ButtonListener myButtonListener = new ButtonListener();  
someButton.addActionListener(myButtonListener); 
... 

class ButtonListener implements ActionListener 
{ 
    public void actionPerformed(ActionEvent e) 
    { 

    } 
}

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

धन्यवाद!

स्रोत

2011-05-23 JPC

आप वहां बटन पर बहुत अधिक हैं। ओबीजे-सी में एकमात्र असली अंतर आम तौर पर प्रतिनिधि द्वारा प्रदान की जा रही वस्तु के बारे में घटनाओं पर विभिन्न कार्यों को करने के लिए कई कार्यों को लागू करता है। उदाहरण के लिए, UITextViewDelegate तरीकों है:

– textViewShouldBeginEditing: 
– textViewDidBeginEditing: 
– textViewShouldEndEditing: 
– textViewDidEndEditing:

केवल वास्तविक अंतर मैंने पाया है कि आपने अपने प्रतिनिधियों इनलाइन जिस तरह से आप की तरह जावा में कर सकते हैं नहीं बना सकते, है:

someButton.setOnClickListener (new View.OnClickListener { 
    @Override 
    public void onClick() { 
     //do stuff 
    } 
});

स्रोत

2011-05-23 20:50:59

तकनीकी रूप से, ब्लॉक का उपयोग करके, आप इनलाइन प्रतिनिधियों को बना सकते हैं। मेरे पास हार्ड ड्राइव पर कहीं भी एक यूटिलिटी क्लास है ... –

ओह सचमुच, मैं उस ऐप में ऐसा कुछ ढूंढ रहा था जिसे मैं एक प्रतिनिधि समारोह के लिए पूरी तरह से नई कक्षा बनाने से बचने के लिए काम कर रहा था। मुझे यह देखना अच्छा लगेगा कि आप –

कैसे करते हैं, यहां आप जाएं: शीर्षलेख: http://pastebin.com/Gdg4nsAF मुख्य: http://pastebin.com/SGVGCB31। आपको प्रत्येक प्रतिनिधि के लिए एक वर्ग बनाना होगा, लेकिन जब आपको उनमें से बहुत कुछ चाहिए, तो इससे कक्षाओं की संख्या कम हो जाएगी। –

वे समान हैं, लेकिन समान नहीं हैं। एक प्रतिनिधिमंडल पैटर्न में व्यापक परिभाषा होती है, और अक्सर क्रियान्वयन परिभाषित कार्य जो अकेले सुनने से परे बढ़ा सकते हैं। कार्यों में सुनना शामिल हो सकता है, या प्रतिनिधि के कार्यान्वयन को सुनने के रूप में परिभाषित किया जा सकता है (विशेष रूप से)।

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

एनएसबटन/UIButton पहले से ही इस मामले के लिए लक्ष्य + क्रिया तंत्र के माध्यम से विशिष्ट रहा है। आप इस विशिष्ट मामले के लिए लक्ष्य + कार्रवाई का उपयोग करेंगे।

स्रोत

2011-05-23 20:52:53 justin

मुझे लगता है कि .NET प्रतिनिधियों के लिए एक बेहतर जावा एनालॉग java.util.concurrent pagkage में मिलेगा: कॉल करने योग्य, भविष्य, निष्पादक।

स्रोत

2011-05-23 21:22:23 duffymo

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

स्रोत

2012-10-18 20:22:08 jack

उद्देश्य-सी प्रतिनिधियों बनाम जावा श्रोताओं

उत्तर

संबंधित मुद्दे