उद्देश्य-सी में श्रेणियों का उपयोग करके तरीकों को ओवरराइड करना


87

क्या मैं एक श्रेणी का उपयोग करके पहले से लागू एक विधि को ओवरराइड करने के लिए एक वर्ग श्रेणी का उपयोग कर सकता हूं? इस कदर:

1) मूल विधि

-(BOOL) method {
  return true;
}

2) ओवररेटेड विधि

-(BOOL) method {
  NSLog(@"error?"); 
  return true; 
}

क्या यह काम करेगा, या यह अवैध है?

जवाबों:


146

से एप्पल प्रलेखन :

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

  • जब कोई श्रेणी विरासत में मिली विधि से आगे निकल जाती है, तो श्रेणी में विधि हमेशा की तरह, एक संदेश के माध्यम से विरासत में प्राप्त कार्यान्वयन को लागू कर सकती है super। हालांकि, यदि कोई श्रेणी किसी विधि को ओवरराइड करती है जो कि श्रेणी के वर्ग में मौजूद है, तो मूल कार्यान्वयन को लागू करने का कोई तरीका नहीं है

  • एक श्रेणी उसी श्रेणी के किसी अन्य श्रेणी में घोषित तरीकों को विश्वसनीय रूप से ओवरराइड नहीं कर सकती है।

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

  • कुछ श्रेणी विधियों की बहुत उपस्थिति से सभी रूपरेखाओं में व्यवहार परिवर्तन हो सकते हैं। उदाहरण के लिए, यदि आप windowWillClose:NSObject पर किसी श्रेणी में प्रतिनिधि पद्धति को ओवरराइड करते हैं , तो आपके कार्यक्रम के सभी विंडो प्रतिनिधि श्रेणी की विधि का उपयोग करके जवाब देते हैं; NSWindow के आपके सभी उदाहरणों का व्यवहार बदल सकता है। आपके द्वारा किसी फ़्रेमवर्क क्लास में जोड़े जाने वाले व्यवहार में रहस्यमय परिवर्तन हो सकते हैं और क्रैश हो सकते हैं।


धन्यवाद, लेकिन मुझे पहले से ही पता है। मुझे बस आश्चर्य है कि मेरा मामला कानूनी है या नहीं। मेरे मामले में दस्तावेजों से थोड़ा अंतर है। :)
रेटिक्स

यह अलग क्यों है? डॉक्टर का कहना है कि यह कानूनी है यदि मूल विधि एक श्रेणी में नहीं है, लेकिन दृढ़ता से हतोत्साहित किया जाता है। फिर आप इसे कर सकते हैं ...
बेनोइट

1
आपकी सलाह के लिए धन्यवाद। मैं इस भाषा में गरीब हूं। मुझे आपसे नई जानकारी मिली है।
रेटिक्स

1
क्या सुपर क्लास की श्रेणी में घोषित और लागू की गई श्रेणी पद्धति में ओवरराइड करना सही है?
BergP

2
लिंक टूट गया है, क्या यह नया संस्करण है? डेवलपर
.apple.com

18

आप क्लास क्लस्टर दृष्टिकोण को अपनाने , या विधियों का उपयोग करके स्वाइलिंग तकनीक का उपयोग करके ऐसा कर सकते हैं ।

अन्यथा, दो या अधिक वर्गीकृत तरीकों का व्यवहार अपरिभाषित है


9

पुराना दस्तावेज़ लिंक मृत है; सबसे अच्छा प्रतिस्थापन मैं यहाँ पा सकता था: Apple डॉक्स :

श्रेणी विधि नाम से बचें

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

यदि किसी श्रेणी में घोषित विधि का नाम मूल वर्ग में एक विधि के समान है, या उसी वर्ग (या यहां तक ​​कि एक सुपरक्लास) पर किसी अन्य श्रेणी में एक विधि है, तो व्यवहार अपरिभाषित है कि किस विधि कार्यान्वयन का उपयोग किया जाता है क्रम। यदि आप अपनी खुद की कक्षाओं के साथ श्रेणियों का उपयोग कर रहे हैं, तो यह एक समस्या है, लेकिन मानक कोको या कोको टच कक्षाओं में तरीकों को जोड़ने के लिए श्रेणियों का उपयोग करते समय समस्याएँ पैदा हो सकती हैं।

यह एक हल्का स्पर्श का उपयोग करके Apple है, लेकिन मुख्य बिंदु समान है: आप आपदा को आमंत्रित करते हैं, क्योंकि अप्रत्याशित व्यवहार चुप है।


2

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

इस ट्यूटोरियल से, http://rypress.com/tutorials/objective-c/categories

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.