मुझे इस पर दो विरोधाभासी विचार मिल रहे हैं। कुछ सूत्रों का कहना है कि विधि कॉल को कम करने के लिए कम कम विधियां होनी चाहिए, लेकिन कुछ अन्य स्रोतों का कहना है कि जेआईटी को अनुकूलन करने के लिए छोटी विधि लिखना अच्छा है।सी #, लंबी विधि या छोटी विधि लिखना?
तो, कौन सा पक्ष सही है?
वास्तव में विधि कॉल करने का ओवरहेड ज्यादातर मामलों में अपरिहार्य रूप से छोटा है। आपको इसके बारे में चिंता करने की आवश्यकता नहीं है जबतक कि आप उस सड़क के नीचे किसी समस्या की स्पष्ट रूप से पहचान नहीं कर सकते जिसके लिए समस्या को फिर से शुरू करने की आवश्यकता है (आप नहीं करेंगे)।
यह बहुत महत्वपूर्ण है कि आपका कोड सरल, पठनीय, मॉड्यूलर, रखरखाव योग्य और संशोधित है। तरीकों को एक चीज करना चाहिए, केवल एक चीज और उप-चीजों को अन्य दिनचर्या में सौंपना चाहिए। इसका मतलब है कि आपकी विधियां जितनी कम हो सकती हैं उतनी छोटी होनी चाहिए, लेकिन कम नहीं। आपको कोड होने से कहीं अधिक प्रदर्शन लाभ दिखाई देंगे जो कि त्रुटि और बग्स से कम प्रवण है क्योंकि यह संकलक या रनटाइम को आउटमार्ट करने की कोशिश करने से सरल है।
स्रोत जो कहता है कि यह मान लंबे समय तक गलत है, कई स्तरों पर।
कोई नहीं, आपके पास पठनीयता प्राप्त करने के लिए अपेक्षाकृत छोटी विधि होनी चाहिए।
फ़ंक्शन आकार के बारे में कोई भी सरल नियम नहीं है। दिशानिर्देश एक समारोह होना चाहिए 'एक बात' करना चाहिए। यह थोड़ा अस्पष्ट है लेकिन अनुभव के साथ आसान हो जाता है। छोटे कार्यों आमतौर पर पठनीयता के लिए नेतृत्व करते हैं। कभी-कभी बड़े होते हैं।
विधि कॉल के ओवरहेड के बारे में चिंता करना समयपूर्व अनुकूलन है।
हमेशा की तरह, यह एक अच्छा संतुलन खोजने के बारे में है। सबसे महत्वपूर्ण बात यह है कि विधि केवल एक चीज है। लंबी विधियों में एक से अधिक चीजें होती हैं।
सबसे पहले, आपको निश्चित रूप से संख्याओं के स्तर पर प्रदर्शन को माइक्रो-ऑप्टिमाइज़ करना नहीं चाहिए। आपको शायद किसी भी मापनीय प्रदर्शन लाभ नहीं मिलेगा। केवल तभी यदि आपके पास कुछ विधि है जो लाखों बार एक तंग पाश में बुलाया जा रहा है, तो यह एक विचार हो सकता है - लेकिन इसकी आवश्यकता होने से पहले इसे अनुकूलित करना प्रारंभ न करें।
आपको संक्षिप्त संक्षिप्त तरीकों से चिपकना चाहिए, जो एक चीज है, जो विधि के इरादे को स्पष्ट करता है। यह आपको आसान-पढ़ने वाला कोड देगा, जो समझना आसान है और कोड पुन: उपयोग को बढ़ावा देता है।
आकार बदलने के तरीकों में आपको मार्गदर्शन करने के लिए सबसे अच्छा एकल मानदंड उन्हें अच्छी तरह से परीक्षण योग्य रखना है। यदि आप (और वास्तव में DO!) पूरी तरह यूनिट-टेस्ट कर सकते हैं, तो आपका कोड काफी अच्छा होने की संभावना है; यदि आप परीक्षण पर कंजूसी करते हैं, तो आपका कोड सबसे अच्छा, मध्यस्थ होने की संभावना है। यदि किसी विधि को पूरी तरह से परीक्षण करना मुश्किल होता है, तो वह विधि "बहुत बड़ी" होने की संभावना है - बहुत सी चीजों को करने की कोशिश कर रहा है, और इसलिए पढ़ने और बनाए रखने के लिए भी कठिन है (साथ ही साथ बुरी तरह से परीक्षण किया गया है और इसलिए संभावित रूप से कीड़े)।
कोड लिखते समय विचार करने की सबसे महत्वपूर्ण लागत रखरखाव है। आप अधिक, अधिक अधिक समय तक एप्लिकेशन को बनाए रखने और बग को ठीक करने से पहले प्रदर्शन समस्याओं को ठीक करने के लिए खर्च करेंगे।
इस मामले में एक बड़ी बुझाने वाली विधि को बनाए रखने की लागत की तुलना में एक विधि को कॉल करने की लगभग निश्चित रूप से महत्वहीन लागत अविश्वसनीय रूप से छोटी है। बनाए रखने और समझने के लिए छोटे संक्षिप्त तरीके आसान हैं। इसके अतिरिक्त विधि को कॉल करने की लागत लगभग निश्चित रूप से आपके आवेदन पर महत्वपूर्ण प्रदर्शन प्रभाव नहीं होगी। और यदि ऐसा होता है, तो आप केवल एक प्रोफाइलर का उपयोग करके दावा कर सकते हैं। हाथ से पहले प्रदर्शन समस्याओं की पहचान करने में डेवलपर्स कुख्यात रूप से खराब हैं।
आम तौर पर, प्रदर्शन की समस्या की पहचान होने के बाद, उन्हें ठीक करना आसान होता है। एक विधि या अधिक महत्वपूर्ण रूप से एक कोड आधार बनाना, रखरखाव बहुत अधिक लागत है।
व्यक्तिगत रूप से, मुझे लंबे समय तक डर नहीं है जब तक कि उन्हें लिखने वाले व्यक्ति उन्हें अच्छी तरह से लिखते हैं (उप-कार्य का प्रत्येक टुकड़ा 2 न्यूलाइनों से अलग होता है और इससे पहले एक अच्छी टिप्पणी आदि। इसके अलावा, पहचान बहुत महत्वपूर्ण है।)। वास्तव में, कई बार मैं उन्हें भी पसंद करता हूं (उदाहरण के लिए जब कोड लिखना जो अनुक्रमिक तर्क के साथ एक विशिष्ट क्रम में चीजें करता है)।
इसके अलावा, मैं वास्तव में समझ में नहीं आता कि 100 टुकड़ों में लंबी विधि को तोड़ने से रीडब्बिलिटी में सुधार होगा (जैसा कि अन्य सुझाव देते हैं)। केवल विपरीत। आप अपने कोड में क्या हो रहा है इसकी एक पूरी तस्वीर प्राप्त करने के लिए बस पूरे स्थान पर कूदते हुए और अपनी याददाश्त में कोड के टुकड़े पकड़ लेंगे। टिप्पणियों की संभावित कमी, खराब कार्य नाम, कई समान कार्य नामों के साथ संयोजन करें और आपके पास अराजकता के लिए एकदम सही नुस्खा है। इसके अलावा, विधियों के आकार को कम करने की कोशिश करते समय आप दूसरे छोर पर जा सकते हैं: कई कक्षाएं और कई कार्यों को बनाने के लिए जिनमें से प्रत्येक कई मानदंड ले सकता है। मुझे नहीं लगता कि इससे पठनीयता में सुधार होता है (विशेष रूप से एक प्रोजेक्ट के लिए एक भिखारी के लिए जिसमें प्रत्येक वर्ग/विधि क्या कोई संकेत नहीं है)।
और मांग "एक कार्य करना चाहिए" एक चीज बहुत ही व्यक्तिपरक है। 'एक चीज' एक ही चीज को 'एक ही चीज़' के लिए माना जाता है कि एक टन काम करने के लिए एक चर हो सकती है।
मेरा नियम केवल पुन: उपयोग करने योग्यता है: एक ही कोड कई स्थानों पर कई बार प्रकट नहीं होना चाहिए। यदि ऐसा है तो आपको एक नया फ़ंक्शन चाहिए। बाकी सभी दार्शनिक बात है। "आप अपनी विधियों को इतना बड़ा क्यों करते हैं" के एक प्रश्न में, "जवाब क्यों आसान है?"।
(केवल मेरी राय - जितना चाहें उतना वोट दें)