रॉबर्ट मैकनेली द्वारा "द कोड कमांड: बेस्ट प्रैक्टिस फॉर ऑब्जेक्टिव-सी कोडिंग" नाम से एक लेख को दो साल पहले पढ़ने के बाद , मैंने अपने ऑब्जेक्टिव-सी कक्षाओं के प्रत्येक डेटा सदस्य के लिए गुणों का उपयोग करने का अभ्यास अपनाया। मई 2012 के अनुसार तीसरी आज्ञा)। McNally ऐसा करने के इन कारणों को सूचीबद्ध करता है (मेरा जोर):
- गुण पहुँच प्रतिबंध लागू करते हैं (जैसे कि आसानी से)
- गुण स्मृति प्रबंधन नीति लागू करते हैं (मजबूत, कमजोर)
- गुण कस्टम सेटर और गेटर्स को पारदर्शी रूप से लागू करने का अवसर प्रदान करते हैं।
- कस्टम सेटर या गेटर्स वाली संपत्तियों का उपयोग थ्रेड-सुरक्षा रणनीति लागू करने के लिए किया जा सकता है।
- उदाहरण चर तक पहुंचने का एक ही तरीका होने से कोड पठनीयता बढ़ जाती है।
मैंने अपनी अधिकांश संपत्तियाँ निजी श्रेणियों में डाल दी हैं, इसलिए नंबर 1 और 4 आमतौर पर मेरे द्वारा चलाए जाने वाले मुद्दे नहीं हैं। तर्क 3 और 5 अधिक 'नरम' हैं, और सही उपकरण और अन्य निरंतरताओं के साथ वे गैर-मुद्दे बन सकते हैं। तो आखिरकार, मेरे लिए इन तर्कों का सबसे प्रभावशाली नंबर 2 था, स्मृति प्रबंधन। मैं तब से ऐसा कर रहा हूं।
@property (nonatomic, strong) id object; // Properties became my friends.मेरी पिछली कुछ परियोजनाओं के लिए मैंने एआरसी का उपयोग करने के लिए स्विच किया है, जिसने मुझे संदेह किया है कि क्या बहुत अधिक कुछ के लिए गुण बनाना अभी भी एक अच्छा विचार है या शायद थोड़ा अतिशयोक्तिपूर्ण है। एआरसी मेरे लिए ऑब्जेक्टिव-सी ऑब्जेक्ट्स को मैनेज करने वाली मेमोरी का ख्याल रखता है, जो कि ज्यादातर strongसदस्यों के लिए ठीक काम करता है अगर आप सिर्फ आइवर घोषित करते हैं। एआरसी से पहले और बाद में सी-प्रकार आपको मैन्युअल रूप से प्रबंधित करना था, और weakगुण ज्यादातर सार्वजनिक हैं।
बेशक, मैं अभी भी उन चीजों के लिए गुणों का उपयोग करता हूं, जिन्हें कक्षा के बाहर से पहुंच की आवश्यकता होती है, लेकिन वे ज्यादातर केवल मुट्ठी भर संपत्तियों के होते हैं, जबकि अधिकांश डेटा सदस्यों को कार्यान्वयन हेडर के तहत ivars के रूप में सूचीबद्ध किया जाता है।
@implementation GTWeekViewController
{
UILongPressGestureRecognizer *_pressRecognizer;
GTPagingGestureRecognizer *_pagingRecognizer;
UITapGestureRecognizer *_tapRecognizer;
}एक प्रयोग के रूप में मैं इसे थोड़ा और सख्ती से कर रहा हूं, और हर चीज के गुणों से दूर जाने के कुछ अच्छे सकारात्मक दुष्प्रभाव हैं।
- डेटा सदस्य कोड आवश्यकताएँ (
@property/@synthesize) केवल ivar घोषणा के लिए सिकुड़ जाती हैं। - मेरे अधिकांश
self.somethingसंदर्भ सिर्फ साफ हो गए_something। - यह आसानी से पहचाना जा सकता है कि कौन से डेटा सदस्य निजी हैं (ivars) और जो सार्वजनिक हैं (गुण)।
- अंत में, ऐसा लगता है कि इस तरह से एप्पल का उद्देश्य था, लेकिन यह व्यक्तिपरक अटकलें थीं।
सवाल पर : मैं धीरे-धीरे अंधेरे पक्ष की ओर फिसल रहा हूं , कार्यान्वयन-आइवर के पक्ष में कम और कम गुणों का उपयोग कर रहा हूं । क्या आप मुझे इस बात के लिए थोड़ा तर्क प्रदान कर सकते हैं कि मुझे हर चीज के लिए गुणों का उपयोग करने से क्यों चिपके रहना चाहिए, या अपने विचारों की वर्तमान ट्रेन की पुष्टि करना चाहिए कि मुझे अधिक ivars और कम गुणों का उपयोग केवल जहां आवश्यकता हो? दोनों पक्षों के लिए सबसे प्रेरक जवाब मेरा निशान प्राप्त करेगा।
EDIT: McNally ने ट्विटर पर कहा, "मुझे लगता है कि गुणों के साथ चिपके रहने का मेरा मुख्य कारण है: सब कुछ करने का एक तरीका, वह सब कुछ करता है (KVC / KVO सहित)।"