मैं इस समय उद्देश्य-सी सीख रहा हूं और प्रोटोकॉल में वैकल्पिक तरीकों से आया हूं। मेरी पृष्ठभूमि सी # है और एक प्रोटोकॉल को सी # इंटरफेस के समान कुछ भी देख सकता है।@optional प्रोटोकॉल विधियों के वास्तविक विश्व उदाहरण
जहां एक सी # इंटरफेस एक इंटरफेस का विज्ञापन करके अनुबंध का प्रतिनिधित्व करता है, तो आप कह रहे हैं कि आप परिभाषित विधियों को लागू करेंगे।
इस बात को ध्यान में रखते हुए मैं उलझन में हूं कि आपको कभी भी वैकल्पिक विधि को परिभाषित करने की आवश्यकता क्यों होगी। यह स्लर या उद्देश्य-सी को कम करने का प्रयास नहीं है, मुझे उद्देश्य-सी पसंद है। भाषा की अधिक समझ हासिल करने के लिए, मैं बस इन वैकल्पिक तरीकों के लाभों को समझना चाहता हूं।
अगर कोई वास्तविक दुनिया परिदृश्य (नमूना कोड के साथ) प्रदान कर सकता है तो मैं वास्तव में इसकी सराहना करता हूं जहां वैकल्पिक विधियां उपयोगी होती हैं।
मुझे लगता है मैं अब यह हो रही है। एक सी # इंटरफेस एक उद्देश्य-सी प्रोटोकॉल का केवल एक पहलू है। आप प्रोटोकॉल को अनुबंध के रूप में उपयोग कर सकते हैं, लेकिन ये वैकल्पिक विधियां वैकल्पिक प्रतिनिधियों की एक सूची बनाती हैं जो एक ऑब्जेक्ट भी प्रतिक्रिया देने का विकल्प चुन सकती हैं। यह वास्तव में दिलचस्प है। प्रतिनिधि कार्यों को दस्तावेज करने के लिए प्रोटोकॉल का उपयोग करने के लिए – kim3er
+1 –
मैं पूरी तरह से @Tom से सहमत हूं। उद्देश्य-सी 2.0 से पहले, किसी भी वर्ग से बचने के लिए एनएसओब्जेक्ट पर एक श्रेणी में प्रतिनिधियों को आम तौर पर घोषित किया जाता था जो सभी विधियों को लागू करने से प्रतिनिधि बनना चाहते हैं। प्रोटोकॉल में वैकल्पिक तरीके एक बहुत साफ समाधान है जो NSObject पर कई तरीकों से निपटता नहीं है, और विधि टकराव से बचने में मदद करता है। यदि केवल जावा में वैकल्पिक इंटरफ़ेस विधियां थीं, तो माउसएडाप्टर से विरासत जैसी चीज़ों की आवश्यकता नहीं होगी। इस तरह की कक्षाओं का उपयोग आमतौर पर कुछ बार होता है जिसे मैंने एकल विरासत को शाप दिया है ... :-) –