2012-06-11 23 views
6

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

उदाहरण:

-(NSDictionary*)serialize 
{ 
    NSMutableDictionary* serialization = [NSMutableDictionary dictionary]; 

    TwoArgumentsBlockType serializeItemBlock = ^void(MyItemClass* item, NSString* identifier) 
    {  
     if (item) 
     { 
      // serialization code 
     } 
    }; 

    serializeItemBlock(self.someItem1, kSomeIdentifier1); 
    serializeItemBlock(self.someItem2, kSomeIdentifier2); 
    serializeItemBlock(self.someItem3, kSomeIdentifier3); 
    serializeItemBlock(self.someItem4, kSomeIdentifier4); 
    serializeItemBlock(self.someItem5, kSomeIdentifier5); 
    serializeItemBlock(self.someItem6, kSomeIdentifier6); 
    serializeItemBlock(self.someItem7, kSomeIdentifier7); 
    serializeItemBlock(self.someItem8, kSomeIdentifier8); 
    serializeItemBlock(self.someItem9, kSomeIdentifier9); 
    serializeItemBlock(self.someItem10, kSomeIdentifier10); 
    serializeItemBlock(self.someItem11, kSomeIdentifier11); 

    return serialization; 
} 
+0

यह एक अच्छा सवाल है, इसने मुझे अलग-अलग सोचने के लिए ब्लॉक्स के साथ अपने एक्स्पेरियंस का उपयोग किया। यह टिप्पणी केस संवेदनशील है;) पी – Lio

उत्तर

1

कोड की स्पष्टता महत्वपूर्ण है।

तरीके .. आप एक दूसरे से अलग कोड के पूरे वर्गों को संपुटित करने की अनुमति है, और यह आसान को पढ़ने के लिए कर सकते हैं

ब्लॉक से अधिक निजी विधि चुननी चाहिए एक और कारण स्मृति प्रबंधन है। यहां पर चर्चा करने के लिए यह विषय बहुत बड़ा है, लेकिन यह कहने के लिए पर्याप्त है कि स्मृति प्रबंधन में ब्लॉक अजीब हैं, और इस संबंध में किसी भी अन्य कोड संरचना की तरह कार्य नहीं करते हैं।

+0

मैं अभी भी पठनीयता के बारे में अनिश्चित हूं। उपर्युक्त कोड में लंबे समय से होने का नुकसान होता है यदि विधि अलग से घोषित की गई थी, लेकिन दूसरी ओर यह मुझे विधि को एक दायरा देने का एक अच्छा तरीका प्रतीत होता है - क्योंकि उस समय इसका उपयोग नहीं किया जाता था कोड में अन्य स्थानों से। – diegoreymendez

+0

किसी भी मामले में मैं समझता हूं कि यह शायद सबसे महत्वपूर्ण कारण है कि कोई इस दृष्टिकोण से बचने का फैसला क्यों करेगा। जवाब के लिए धन्यवाद। – diegoreymendez

1

यकीनन यह कोड नेविगेट करने के लिए कठिन है - आप प्रवेश बिंदुओं बल्कि कुछ समारोह के बीच में प्रच्छन्नतापूर्वक दफन हो जाते हैं, और कोई समारोह नाम आप डिबगर या खोज में देख सकते हैं के लिए, जो डिबगिंग और थोड़ा कठिन पता लगा सकता है।

6

मुझे लगता है कि 3 सबसे बड़ी कमियां हैं:

  1. ब्लॉक के रूप में आप का उल्लेख, पुन: प्रयोज्य नहीं है।
  2. ब्लॉक परीक्षण योग्य नहीं है - आप एक इकाई परीक्षण नहीं लिख सकते हैं जो ब्लॉक को सत्यापित करता है जो आपको लगता है कि वह करता है।
  3. कोड कम पठनीय है। जब आप इस विधि को पढ़ रहे हों, तो महत्वपूर्ण बात यह है कि चीजों की एक श्रृंखला धारावाहिक होती है, न कि क्रमबद्धता को कैसे कार्यान्वित किया जाता है।

इस ब्लॉक को एक विधि में ले जाने से इन सभी मुद्दों को हल किया जाएगा। यदि कुछ एपीआई द्वारा ब्लॉक का उपयोग किया जाता है जो एक ब्लॉक कॉलबैक को तर्क के रूप में लेता है, तो आप हमेशा return the block from a method कर सकते हैं।

+0

मेरा मानना ​​है कि मेरे प्रारंभिक प्रश्न के साथ समस्या का हिस्सा यह है कि इसका उत्तर यह है: "यह आपकी आवश्यकता पर निर्भर करता है"। उदाहरण के लिए: ब्लॉकों को इतना दिलचस्प बनाता है कि वे डेवलपर्स को इनलाइन विधियों को लिखने की अनुमति देते हैं जहां यह वास्तव में समझ में आता है - उदाहरण के लिए जहां आपको कोड निष्पादित करने की आवश्यकता होती है जो वास्तव में कहीं और नहीं है, और उन जगहों पर जहां पठनीयता यदि आप बाहरी विधि का उपयोग करते हैं तो पीड़ित हैं। – diegoreymendez

संबंधित मुद्दे