उद्देश्य-सी निजी विधियों का समर्थन क्यों नहीं करता है?

123

मैंने उद्देश्य-सी में अर्ध-निजी तरीकों की घोषणा के लिए कई रणनीतियां देखी हैं , लेकिन वास्तव में निजी पद्धति बनाने का कोई तरीका नहीं लगता है। मुझे यह मंजूर है। लेकिन, ऐसा क्यों है? प्रत्येक स्पष्टीकरण जो मैं अनिवार्य रूप से कहता हूं, "आप ऐसा नहीं कर सकते, लेकिन यहां एक निकट सन्निकटन है।"

कीवर्ड के एक नंबर के लिए आवेदन किया हैं ivars(सदस्य) है कि उनके गुंजाइश है, जैसे को नियंत्रित @private, @public, @protected। यह तरीकों के लिए भी क्यों नहीं किया जा सकता है? ऐसा लगता है कि रनटाइम को समर्थन देने में सक्षम होना चाहिए। क्या कोई अंतर्निहित दर्शन मुझे याद आ रहा है? क्या यह जानबूझकर है?

objective-c objective-c-runtime

— रॉब जोन्स
स्रोत

15

अच्छा सवाल है, बी.टी.वी.

— बीबीम

5

आपके संपादन के लिए: हाँ, रनटाइम प्रवर्तन बहुत कम लाभ के लिए बहुत महंगा होगा। संकलन-समय प्रवर्तन भाषा के लिए एक स्वागत योग्य अतिरिक्त होगा और यह काफी प्राप्य है। हां, इसे रनटाइम पर दरकिनार किया जा सकता है, लेकिन यह ठीक है। प्रोग्रामर दुश्मन नहीं है। गुंजाइश का लक्ष्य प्रोग्रामर को त्रुटि से बचाने में मदद करना है।

— रॉब नेपियर

1

आप "रनटाइम को छोड़ नहीं सकते" - रनटाइम वह है जो संदेश प्रेषण करता है।

— चक

" इस चेक को शॉर्ट-सर्किट करने के लिए एक निजी पद्धति का कोई रास्ता नहीं होगा " क्या आपका मतलब "चक्कर" था? ;-)

— कॉन्स्टेंटिनो त्सारोहस

103

जवाब है ... अच्छा ... सरल। सादगी और निरंतरता, वास्तव में।

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

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

रनटाइम में समान कार्यक्षमता को डुप्लिकेट करने के लिए बहुत कम लाभ है। यह जटिलता और ओवरहेड की एक जबरदस्त मात्रा जोड़ देगा। और उस जटिलता के सभी के साथ, यह अभी भी सभी लेकिन सबसे आकस्मिक डेवलपर को आपके "निजी" तरीकों को निष्पादित करने से नहीं रोक पाएगा।

संपादित करें: एक धारणा जो मैंने देखी है वह यह है कि निजी संदेशों को रनटाइम के माध्यम से जाना होगा, जिसके परिणामस्वरूप संभावित रूप से बड़े ओवरहेड हो सकते हैं। क्या यह बिल्कुल सच है?

हाँ यही है। यह मानने का कोई कारण नहीं है कि किसी वर्ग का कार्यान्वयनकर्ता कार्यान्वयन में सेट किए गए सभी उद्देश्य-सी सुविधा का उपयोग नहीं करना चाहेगा, और इसका अर्थ है कि गतिशील प्रेषण अवश्य होना चाहिए। हालांकि , कोई विशेष कारण नहीं है कि निजी तरीकों को एक विशेष संस्करण द्वारा नहीं भेजा जा सकता है objc_msgSend(), क्योंकि कंपाइलर को पता चल जाएगा कि वे निजी थे; अर्थात यह Classसंरचना में एक निजी-केवल विधि तालिका जोड़कर प्राप्त किया जा सकता है ।

इस चेक को शॉर्ट-सर्किट करने या रनटाइम को छोड़ने के लिए कोई निजी तरीका नहीं होगा?

यह रनटाइम को छोड़ नहीं सकता है, लेकिन रनटाइम को निजी तरीकों के लिए कोई भी जांच करने की आवश्यकता नहीं होगी ।

उस ने कहा, ऐसा कोई कारण नहीं है कि कोई तृतीय-पक्ष जानबूझकर objc_msgSendPrivate()किसी वस्तु पर कॉल नहीं कर सकता , उस वस्तु के कार्यान्वयन के बाहर, और कुछ चीजें (उदाहरण के लिए केवीओ) को ऐसा करना होगा। वास्तव में, यह निजी तरीकों के चयनकर्ताओं को उपसर्ग करने या इंटरफ़ेस हेडर में उनका उल्लेख नहीं करने की तुलना में बस एक सम्मेलन और थोड़ा बेहतर होगा।

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

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

— bbum
स्रोत

49

+1 ऑब्जेक्टिव-सी (कुछ मायनों में) एक "बिग-बॉय" भाषा है, जिसमें प्रोग्रामर को हर मोड़ पर कंपाइलर / रनटाइम द्वारा हाथ पर थप्पड़ मारने के बजाय अनुशासन की एक निश्चित मात्रा का प्रदर्शन करने की उम्मीद की जाती है। मुझे यह ताज़ा लग रहा है। मेरे लिए, संकलन / लिंकिंग के दौरान विधि दृश्यता को सीमित करना पर्याप्त और बेहतर है।

— क्विन टेलर

11

अधिक अजगर "obj-c-ic" :)। Guido NeXT सिस्टम पर पायथन को बनाए रखने में काफी सक्रिय था, जिसमें PyObjC का 1 संस्करण बनाना शामिल था। इस प्रकार, ओजेसीसी ने अजगर को कुछ हद तक प्रभावित किया ।

— बीबीम

3

जीवन के लिए परोपकारी तानाशाह की दिलचस्प ऐतिहासिक कहानी के लिए +1 और पौराणिक NeXT प्रणाली के साथ उनके क्रॉसिंग।

— पोकस्टेड

5

धन्यवाद। पायथन, जावा और ऑब्जेक्टिव-सी सभी में रनटाइम ऑब्जेक्ट मॉडल होते हैं, जो कि [छोटे से छोटे] के समान होते हैं। जावा काफी सीधे ऑब्जेक्टिव-सी से लिया गया था। पाइथन ने एक प्रेरणा से अधिक एक समानांतर पाठ्यक्रम चलाया, लेकिन गुइडो ने निश्चित रूप से नेक्स्टस्टेप का बारीकी से अध्ययन किया।

— बीबीम

1

सिवाय इसके कि मुझे इसके लाइसेंस पर भरोसा नहीं है और मैं निश्चित रूप से gcc के लिए क्लैंग को प्राथमिकता दूंगा। लेकिन यह सुनिश्चित करने के लिए एक अच्छा पहला कदम है।

— चेट्टू

18

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

इसके अलावा, रनटाइम को यह सत्यापित करने की आवश्यकता होगी कि निजी संदेश भेजने वाला रिसीवर के समान वर्ग का है। आप निजी तरीकों को भी बायपास कर सकते हैं; यदि कक्षा का उपयोग किया जाता है instanceMethodForSelector:, तो यह IMPकिसी अन्य वर्ग को उनके लिए सीधे निजी पद्धति को लागू करने के लिए वापस दे सकता है ।

निजी तरीके संदेश प्रेषण को बायपास नहीं कर सके। इस परिदृश्य पर विचार करें:

एक कक्षा AllPublicमें एक सार्वजनिक उदाहरण विधि होती हैdoSomething
एक अन्य वर्ग के HasPrivateपास एक निजी उदाहरण विधि भी होती हैdoSomething
आप एक सरणी बनाते हैं जिसमें किसी भी संख्या में दोनों के उदाहरण हैं AllPublicऔरHasPrivate
आपके पास निम्नलिखित लूप है:
```
for (id anObject in myArray)
    [anObject doSomething];
```
यदि आप उस लूप को भीतर से चलाते हैं AllPublic, तो रनटाइम को आपको इंस्टेंसेस doSomethingपर भेजना बंद करना होगा HasPrivate, हालाँकि यह लूप तब उपयोगी होगा जब वह HasPrivateक्लास के अंदर हो ।

— dreamlax
स्रोत

1

मैं मानता हूं कि इसमें एक लागत शामिल होगी। शायद यह कुछ ऐसा नहीं है जिसे आप एक हाथ में डिवाइस पर चाहते हैं। आप अन्यथा विशाल योग्यता का समर्थन कर सकते हैं? क्या लागत वास्तव में एक डेस्कटॉप सिस्टम पर होगी?

— रोब जोंस

1

हालांकि उस पर नहीं है, लेकिन आप सही हो सकते हैं। ऑब्जेक्टिव-सी में रन-टाइम मैसेज डिस्पैच बनाम C ++ का कंपाइल टाइम मेथड कॉल है, इसलिए आप कंपाइल टाइम चेक बनाम रन-टाइम चेक की बात कर रहे होंगे।

— रेमस रूसु

यह वास्तव में अजीब लगता है कि निजी तरीकों का समर्थन नहीं करने का मुख्य कारण प्रदर्शन के कारण है। मुझे लगता है कि Apple ने नहीं सोचा था कि निजी तरीके बहुत आवश्यक थे, चाहे कोई प्रदर्शन हिट था या नहीं। अन्यथा उन्हें अपनी बहु-अरब डॉलर की कंपनी के लिए एक अलग भाषा चुननी चाहिए।

— पोकस्टेड

1

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

— जेन्स एटन

7

क्या निजी तरीके आपको खरीदेंगे, वास्तव में? उद्देश्य-सी, आखिरकार, एक सी आधारित भाषा है। इस प्रकार, यदि किसी के पास आपकी प्रक्रिया में कोड चल रहा है, तो वे आपकी प्रक्रिया को आसानी से p0wnz कर सकते हैं, भले ही कोई भी API कैसा भी हो, निजी तौर पर या किसी भी प्रकार की बाधा न हो।

— बीबीम

13

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

@interface MyObject : NSObject {}
- (void) doSomething;
@end

यदि आपको "निजी" तरीकों की आवश्यकता है, तो आप इसे कार्यान्वयन फ़ाइल में भी डाल सकते हैं:

@interface MyObject (Private)
- (void) doSomeHelperThing;
@end

@implementation MyObject

- (void) doSomething
{
    // Do some stuff
    [self doSomeHelperThing];
    // Do some other stuff;
}

- (void) doSomeHelperThing
{
    // Do some helper stuff
}

@end

निश्चित रूप से, यह C ++ / Java निजी विधियों के समान नहीं है , लेकिन यह प्रभावी रूप से पर्याप्त रूप से बंद है, इसलिए भाषा के शब्दार्थों के साथ-साथ संकलक, रनटाइम इत्यादि को भी बदल दें, ताकि पहले से ही स्वीकार्य में एक फीचर जोड़ा जा सके। मार्ग? जैसा कि अन्य उत्तरों में उल्लेख किया गया है, संदेश-गुजरने वाले शब्दार्थ - और रनटाइम प्रतिबिंब पर उनकी निर्भरता - "निजी" संदेशों को गैर-तुच्छ बना देगा।

— mipadi
स्रोत

1

इस दृष्टिकोण के साथ समस्या यह है कि कोई व्यक्ति निजी तरीकों (यहां तक कि अनजाने में) को ओवरराइड कर सकता है जब वे आपकी कक्षा को उपवर्गित करते हैं। मुझे लगता है, अनिवार्य रूप से आपको उन नामों का चयन करना होगा जिनकी ओवरराइड होने की संभावना नहीं है।

— ड्रीमलैक्स

3

जो मुझे एक हैक के ऊपर एक हैक की तरह लगता है।

— रोब जोन्स

1

@ माइक: ऐप्पल ने कहा है कि प्रमुख अंडरस्कोर वाले विधि नाम स्पष्ट रूप से केवल ऐप्पल के लिए आरक्षित हैं: डेवलपर . apple.com/mac/library/documentation/Cocoa/Conceptual/… । अनुशंसित विकल्प दो कैपिटल अक्षरों और फिर एक अंडरस्कोर के साथ उपसर्ग करना है ।

— ड्रीमलैक्स

8

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

— पोकस्टेड

2

यदि आप उन तरीकों के बारे में चिंतित हैं जिन्हें आप ओवरराइड होने को परिभाषित करते हैं, तो आपने उद्देश्य-सी को प्रोत्साहित करने वाले

— क्रियात्मकता

7

सबसे आसान उपाय यह है कि आप अपने Objective-C कक्षाओं में कुछ स्थिर C फ़ंक्शन घोषित करें। इनमें केवल स्थिर कीवर्ड के लिए सी नियमों के अनुसार फाइल स्कोप है और इसके कारण वे केवल उस क्लास में विधियों द्वारा उपयोग किए जा सकते हैं।

कोई उपद्रव नहीं।

— cromulent
स्रोत

क्या इन्हें @ कार्यान्वयन अनुभाग के बाहर परिभाषित किया जाना है?

— रॉब जोन्स

@Rob - नहीं वे (और सबसे अधिक संभावना होनी चाहिए) आपकी कक्षाओं के कार्यान्वयन के अंदर परिभाषित की गई हैं।

— Cromulent

6

हां, यह संकलक को प्रभावित करने के बिना संकलक (एस) द्वारा नियोजित तकनीक का उपयोग करके किया जा सकता है सी ++: नाम-प्रबंध।

यह नहीं किया गया है क्योंकि यह स्थापित नहीं किया गया है कि यह कोडिंग समस्या स्थान में कुछ काफी कठिनाई को हल करेगा कि अन्य तकनीकों (जैसे, उपसर्ग या अंडरस्कोरिंग) पर्याप्त रूप से चक्कर लगाने में सक्षम हैं। IOW, आपको निगली हुई आदतों को दूर करने के लिए अधिक दर्द की आवश्यकता है।

आप पैच को क्लैंग या जीसीसी में योगदान कर सकते हैं जो सिंटैक्स में निजी तरीकों को जोड़ते हैं और उत्पन्न नामों को उत्पन्न करते हैं कि यह अकेले संकलन के दौरान मान्यता प्राप्त है (और तुरंत भूल गया)। तब उद्देश्य-सी समुदाय के अन्य लोग यह निर्धारित करने में सक्षम होंगे कि यह वास्तव में सार्थक था या नहीं। यह डेवलपर्स को समझाने की कोशिश की तुलना में तेजी से होने की संभावना है।

— Huperniketes
स्रोत

2

संकलन समय नाम mangling बहुत कठिन के रूप में आप उन है कि XIB फ़ाइलों में दिखाई दे सकते हैं और उन है कि NSSelectorFromString () के साथ-साथ KeyValueCoding और दोस्तों की तरह बातें करने के लिए पारित किया जा सकता है ... सहित सभी विधि चयनकर्ताओं, वध करने के लिए है एक से मान सकता है

— बीबीएम

1

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

— हपरनिकेतेस

1

एक संकलन-समय-केवल प्रवर्तन + नाम-मानवकरण किसी को किसी वर्ग की विधि सूची को चलना और उसमें ढूंढने से कैसे रोक देगा?

— ड्रीमलैक्स

यह नहीं होगा मेरा जवाब केवल ओपी द्वारा पूछे गए प्रश्न को संबोधित करता है।

— हपरनिकेतेस

मैंने क्लैंग में निजी तरीकों को जोड़ने की कोशिश में जाने के बारे में सोचा है, एक कारण मुझे लगा कि निजी तरीके अच्छे होंगे कि उन्हें सीधे सी कार्यों की तरह बुलाया जा सकता है और फिर आप सभी सामान्य सी फ़ंक्शन अनुकूलन हो सकते हैं। मैंने समय के कारण कभी परेशान नहीं किया है और आप पहले से ही सी का उपयोग करके ऐसा कर सकते हैं।

— नाथन दिवस

4

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

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

— चक
स्रोत

1

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

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

— pokstad
स्रोत

और अगर आपके काम के उपभोक्ता आपके निजी तरीकों को प्रतिबिंबित कर सकते हैं, तो क्या वे उन्हें भी नहीं बुला सकते हैं?

— जारेड अपडेटाइक

यदि वे जानते हैं कि कहां देखना है, तो क्या यह नहीं है कि लोग iPhone पर अनिर्दिष्ट पुस्तकालयों का उपयोग कैसे कर रहे हैं? IPhone के साथ समस्या यह है कि आप किसी भी निजी API का उपयोग करने के लिए अपना ऐप स्वीकार नहीं करने का जोखिम उठाते हैं।

— पोकस्टैड

यदि वे प्रतिबिंब के माध्यम से निजी तरीकों का उपयोग करते हैं, तो उन्हें वह मिलता है जिसके वे हकदार हैं। कोई भी त्रुटि आपकी गलती नहीं है।

— gnasher729

1

प्रश्न की व्याख्या के आधार पर दो उत्तर हैं।

पहला इंटरफ़ेस से विधि कार्यान्वयन को छिपाकर है। इसका उपयोग आम तौर पर बिना नाम वाले श्रेणी के साथ किया जाता है (जैसे @interface Foo())। यह उन संदेशों को भेजने के लिए ऑब्जेक्ट को अनुमति देता है, लेकिन दूसरों को नहीं - हालांकि कोई अभी भी गलती से (या अन्यथा) ओवरराइड कर सकता है।

दूसरा जवाब, इस धारणा पर कि यह प्रदर्शन और इनलाइनिंग के बारे में है, यह संभव है, लेकिन इसके बजाय स्थानीय सी फ़ंक्शन के रूप में। यदि आप एक 'निजी फू ( NSString *arg) विधि चाहते हैं, तो आप void MyClass_foo(MyClass *self, NSString *arg)इसे सी फ़ंक्शन की तरह करेंगे MyClass_foo(self,arg)। वाक्य-विन्यास अलग है, लेकिन यह C ++ के निजी तरीकों के प्रदर्शन की विशिष्ट प्रकार की विशेषताओं के साथ काम करता है।

यद्यपि यह प्रश्न का उत्तर देता है, मुझे यह इंगित करना चाहिए कि नो-नाम श्रेणी ऐसा करने का अधिक सामान्य उद्देश्य-सी तरीका है।

— AlBlue
स्रोत

0

उद्देश्य-सी निजी तरीकों का समर्थन नहीं करता है क्योंकि उन्हें उनकी आवश्यकता नहीं है।

C ++ में, प्रत्येक विधि को कक्षा की घोषणा में दिखाई देना चाहिए। आपके पास ऐसी विधियाँ नहीं हो सकती हैं जिनमें हेडर फ़ाइल सहित कोई भी नहीं देख सकता है। इसलिए यदि आप ऐसी विधियाँ चाहते हैं जो आपके कार्यान्वयन के बाहर कोड का उपयोग न करें, तो आपके पास कोई विकल्प नहीं है, संकलक को आपको कुछ उपकरण देना होगा ताकि आप यह बता सकें कि विधि का उपयोग नहीं किया जाना चाहिए, यह "निजी" कीवर्ड है।

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

उदाहरण के लिए चर, जो आपको हेडर फ़ाइल (अब नहीं) में घोषित करने के लिए इस्तेमाल किया जाता था, @ प्रालिट, @public और @protected उपलब्ध हैं।

— gnasher729
स्रोत

0

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

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

— Stephan Eggermont
स्रोत

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

— अलास्टेयर जूल