संभव डुप्लिकेट:
What describes @property(…) best? What's that actually good for?मुझे @properties का उपयोग क्यों करना चाहिए?
अगर मैं अपने वर्ग इंटरफ़ेस में एक चर घोषित, मैं इस तरह के चर कहीं भी मेरी कक्षा पर उपयोग कर सकते हैं। बहुत बढ़िया।
यदि मैं @property (retain) Something *myVar; का उपयोग करता हूं तो मैं उस चर को self.myVar के साथ एक्सेस कर सकता हूं ... लेकिन, क्या अंतर है? क्या कोई अच्छा कारण है कि मुझे एक विधि या किसी अन्य का उपयोग करना चाहिए?
संक्षिप्त उत्तर: स्मृति प्रबंधन का Encapsulation।
लंबा उत्तर: यदि आप इसे बाद में उपयोग करना चाहते हैं तो आपको किसी ऑब्जेक्ट के स्वामित्व को स्थापित करने की आवश्यकता है। यदि आप इसे बाद में उपयोग करना चाहते हैं, तो आपको इसके संदर्भ में इसकी आवश्यकता होगी जिसके साथ ऐसा करना है, और उस संदर्भ को रखने के लिए एक शानदार जगह एक आवृत्ति चर में है।
आप स्वामित्व का दावा है (यानी बरकरार रखे हुए है और विज्ञप्ति) हर बार जब आप उस के लिए एक नया मूल्य निर्दिष्ट है, लेकिन वह चेरी की तरह जगह सभी बिखरे हुए दुहराव और परेशानी की आशंका वाले बॉयलरप्लेट कोड का एक बहुत कुछ छोड़ना होगा, संभाल सकता एक फलकेक में उस तरह की गड़बड़ी डीबग करना बेहद मुश्किल है जब (अगर नहीं) कुछ गलत हो जाता है। तो, उस कोड को एक्सेसर विधियों में लपेटना कहीं बेहतर है, ताकि आप इसे एक बार लिख सकें और फिर इसके बारे में भूल जाएं।
लेकिन एक्सेसर विधियां अधिकतर बॉयलरप्लेट भी हैं, इसलिए हम उन्हें हाथ से लिखने के बजाए स्वचालित रूप से उन्हें बनाने के लिए @property घोषणाओं का उपयोग करते हैं।
संपादित: एप्पल के Memory Management Guide एक क्या एक्सेसर @property द्वारा उत्पन्न तरीकों पर्दे के पीछे कर के बारे में विस्तार की बहुत प्रदान करता है।
तो मैंने जिस पहली विधि का उल्लेख किया है वह स्वामित्व स्थापित नहीं करता है और इसलिए मैं इसे भविष्य में खो सकता हूं? मुझे लगता है कि मैं बस सबकुछ के लिए गुणों का उपयोग करूंगा = /। एक आखिरी बात: अगर मैं Dealloc विधि में self.myProperty = nil का उपयोग करता हूं (जब मुझे इसकी आवश्यकता नहीं है) मैं ठीक हूँ, है ना? मुझे [self.myProperty रिलीज] या कुछ भी कहना नहीं है? – Voldemort
नहीं, ऑब्जेक्ट को + ऑलोक, -कोपी, या -मेटेबल कॉपी के साथ ऑब्जेक्ट बनाने या इसे एक-एक संदेश भेजने के द्वारा स्थापित किया गया है। कोई फर्क नहीं पड़ता कि आप स्वामित्व कैसे स्थापित करते हैं, आपको इसे एक संदेश भेजकर देना होगा। और वहां रगड़ है - हर बार जब आप अपने आवृत्ति चर के लिए एक नया मान आवंटित करते हैं, तो आपको पुराने को रिलीज़ करने की आवश्यकता होती है, और आपको यह सुनिश्चित करने की आवश्यकता होती है कि इन सभी स्वामित्व दावों को संतुलित रहें। –
ऐसा करने के लिए सबसे आसान है कि स्वामित्व स्थापित करने वाले सृजन विधियों से बचें, या जब आप उन्हें उपयोग करना चाहते हैं, तो सावधानीपूर्वक उपयोग करें, और बस संपत्ति असाइनमेंट को शेष को संभालने दें। –
अपने ivars तक पहुंचने के लिए @property का उपयोग करके, आपके लिए वस्तुओं को जारी करने और बनाए रखने के दोहराव कोड हैं। आपको उनका उपयोग करने की ज़रूरत नहीं है। यह बहुत सारे ट्यूटोरियल हैं जो मंच के लिए नए लोगों के लिए आसान बनाते हैं।
यदि मैं @property (बनाए रखना) कुछ * myVar का उपयोग करता हूं; मैं self.myVar के साथ उस चर का उपयोग कर सकता हूं ... लेकिन, क्या अंतर है?
@property (retain) Something *myVar;
// this property declaration declares:
- (Something *)myVar;
// and
- (void)setMyIvar:(Something *)arg;
// and is accessible by dot syntax.
// it also declares and/or documents how the ivar is managed (copy, retain, etc.)
:
// direct access to the ivar. zero additional overhead (with regard to accessing the ivar)
[myVar message];
// properties used with dot syntax invoke the accessor. therefore,
[self.myVar message];
// is the same as:
[[self myVar] message];
संपत्ति के गुण भी कैसे एक्सेसर के संश्लेषण के लिए के रूप में संकलक को निर्देश देने के।
क्या कोई अच्छा कारण है कि मुझे एक विधि या किसी अन्य का उपयोग करना चाहिए?
init और dealloc में, सीधे ivar तक पहुंचें - आप ऑब्जेक्ट के इवर की शुरुआत और सफाई में रुचि रखते हैं और उप-वर्गों की परवाह नहीं करते हैं। यहां गुणों का उपयोग करने से बग या अपरिभाषित व्यवहार भी शुरू हो सकता है।
अन्य मामलों के लिए, यानी, जब ऑब्जेक्ट पूरी तरह से निर्मित राज्य में होता है, तो आपको हमेशा स्थिरता के लिए एक्सेसर का उपयोग करना चाहिए।यदि एक सबक्लास एक एक्सेसर को ओवरराइड करता है, तो इवर की सीधी पहुंच डिज़ाइन तोड़ सकती है।
यदि आप इससे बचना चाहते हैं, तो ivar निजी बनाएं और इसके लिए कोई संपत्ति घोषित न करें। यदि आप इसके लिए एक संपत्ति घोषित करते हैं, तो दस्तावेज कि यह निजी है; मैं आमतौर पर इस मामले में @property (retain) Something * private_myIvar; लिखूंगा। इस मामले में, ivar के स्मृति प्रबंधन को synthseize करने के लिए एक संपत्ति का उपयोग करना सुविधाजनक है।
जब इवर निजी है, तो आपके पास इसकी कुल पहुंच है। सीधे या निजी संपत्ति तक पहुंच सुरक्षित है। अन्यथा, मान लीजिए कि आपको एक्सेसर का उपयोग करना होगा।
यदि myIvar निजी घोषित किया गया है और केवल प्रारंभ में ही बनाया जाएगा, तो आप संपत्तियों को पूरी तरह से घोषित करने से बच सकते हैं। यह रनटाइम ओवरहेड को कम करेगा (यदि यह महत्वपूर्ण है)। मैसेजिंग ओवरहेड, चक्रों को बनाए रखना/छोड़ना, और परमाणु (स्वाभाविक रूप से) अधिक निष्पादन समय की आवश्यकता होगी। इसलिए इसे प्रदर्शन में सुधार के लिए बाईपास किया जा सकता है।
दृश्यता/रखरखाव। कभी-कभी, इंटरफ़ेस से ivar को छिपाने के लिए यह बहुत कम रखरखाव/कार्यान्वयन है। अन्य मामलों में, इवर कक्षा का कार्यान्वयन विवरण है, और सार्वजनिक इंटरफ़ेस का हिस्सा नहीं होना चाहिए। ऐसे मामलों में, इसे निजी बनाने पर विचार करें (ओबीजेसी में इसे जमा करने के कुछ तरीके हैं)।
मुझे विश्वास है कि इसे गेटटर/सेटर विधियों को बनाना चाहते हैं या नहीं, लेकिन मुझे उस पर उद्धरण न दें। कोको दिग्गजों के बीच यह सामान्य ज्ञान है, मुझे यकीन है कि कोई जल्द ही इसका उत्तर देगा :) –