क्या कोड के लिए निजी विधियों को निकालने लायक है जो केवल कक्षा में एक बार बुलाया जाता है, या एक टिप्पणी के साथ मूल विधि (शायद) में कोड छोड़कर यह कहता है कि यह क्या करता है?क्या आपको निजी तरीकों से कोड को दोबारा संशोधित करना चाहिए यदि उन्हें एक से अधिक बार नहीं कहा जाता है?
यदि कोड के इरादे को स्पष्ट करता है तो यह हमेशा विधियों को निकालने लायक है।
यह विशेष रूप से बहुत लंबी विधियों के लिए सच है। हालांकि टिप्पणियां ठीक हैं, वे चित्रित नहीं करते हैं (कम से कम एक ठोस तरीके से नहीं) जहां यह प्रक्रिया समाप्त होती है और कहां से शुरू होता है। कभी-कभी सामान्य अवशोषण के बाद केवल अधिक स्पष्ट हो जाएगा, आपने विधि निकाली है।
यदि आप स्वचालित इकाई-परीक्षण (आवश्यक रूप से टीडीडी नहीं) में हैं, तो यूनिट परीक्षण विधियों के छोटे टुकड़ों के लिए यह बहुत आसान होगा - हालांकि आपको इसके लिए अपने तरीके सार्वजनिक करना पड़ सकता है, परीक्षण फ्रेमवर्क जो आप उपयोग करते हैं।
बिंदु यह है कि आप छोटी विधियों के साथ गलत नहीं जा सकते हैं, खासकर अगर उनके पास वर्णनात्मक नाम हैं।
मैं बहुत सहमत हूं। मैं हर समय इस तरह से प्रतिक्रिया करता हूं और जिस डिग्री से यह कोड को पठनीयता जोड़ता है वह जबरदस्त है। अबास्ट्रक्शन एक छोटी (उदा। 1-लाइन) विधि के स्तर तक भी बहुत उपयोगी है। इस तरह से रिफैक्टरिंग आपकी मूल विधि के प्रवाह को देखने और मुख्य विधि या उसके किसी भी घटक के डिजाइन या कार्यान्वयन को बदलने के लिए बहुत आसान बनाता है। – Wedge
मैं इस उत्तर के बारे में सोच रहा हूं। मुझे लगता है कि आपको बदलना चाहिए "कहां छोटे तरीकों से गलत नहीं हो सकता है, खासकर अगर उनके पास वर्णनात्मक नाम हैं।" "यदि विधियों में वर्णनात्मक नाम नहीं है तो आप केवल गलत हो सकते हैं" – mcintyre321
बेशक! आपके तरीकों को छोटा, आपके सॉफ़्टवेयर को बनाए रखना आसान है।
1-लाइनर के साथ क्या गलत है? यदि वह आपको आवश्यक encapsulation का स्तर है, तो वह है। यह मानते हुए कि 1-लाइन विधि "असली विधि" होने के लिए "मांसपेशियों के लिए पर्याप्त" नहीं है, बौद्धिक रूप से सीमित है। 1-लाइन विधियों की तलाश करना शुरू करें जिन्हें निकाला जा सकता है जो उपयोगी होगा, आपको शायद लगता है कि आप इससे अधिक पाएंगे। – Wedge
हां, आप बिल्कुल सही हैं, मुझे यह नहीं कहना चाहिए था "(ठीक है, एक-लाइनर निश्चित रूप से बहुत उपयोगी नहीं होंगे।)" इस तरह के एक निश्चित तरीके से ... यह नहीं जानते कि इसे बेहतर तरीके से कैसे लिखना है आपने पहले ही किया है, इसलिए मुझे लगता है कि मैं बस उस वाक्य को हटा दूंगा। :-) धन्यवाद! – Arjan
ऐसा करने में बहुत बड़ा लाभ है। यह जानकारी छिपाने के बारे में है, और इरादों को बहुत स्पष्ट बना रहा है।
कोड को रिफैक्टरिंग में उन्होंने इस रचना विधियों को बुलाया जहां आप कई छोटी विधियों में एक बड़ी विधि को तोड़ते हैं। यह दो चीजें करता है।
सबसे पहले यह उस जानकारी की मात्रा को कम करता है जिसे आपको मूल विधि पर काम करते समय चिंता करने की आवश्यकता होती है।
दूसरा, विधि का नाम इसके इरादे को इंगित करना चाहिए जो कोड को और अधिक पठनीय बनाता है।
यह वैरिएबल स्कोप मुद्दों को भी बहुत आसान बनाता है। वेरिएबल्स का उपयोग करने के लिए कोड की 100-पंक्तियों को स्कैन करना एक दर्जन लाइनों से कम की विधि की जांच करने की तुलना में समय की एक गैर-तुच्छ बर्बादी है। – Wedge
हां, यह है।
एक अतिरिक्त बिंदु: सरल सहायक तरीकों के लिए, आप उन्हें स्थिर बनाना चाहते हैं (जैसे कि वे अपने उदाहरण की स्थिति पर निर्भर नहीं हैं या बदलते हैं), तो आप उन्हें आसानी से पुन: उपयोग के लिए भी सार्वजनिक कर सकते हैं।
मेरे लिए यह इस बात पर निर्भर करता है कि कोड कितना बड़ा है, और मूल विधि क्या है उससे संबंधित है। यदि यह बहुत कोड है (कोड की 5-10 से अधिक पंक्तियां, या पैरेंट विधि में कोड की कुल राशि का 50% से अधिक कहें) मैं कोड संरचना और पठनीयता के लिए इसे एक निजी विधि में निकाल दूंगा। अन्यथा मैं इसे एक वर्णनात्मक टिप्पणी के साथ मूल विधि में छोड़ दूंगा।
मुझे लगता है कि अगर कोड में बहुत कम, बहुत छोटी विधियां हैं तो रखरखाव और पठनीयता को अपमानित किया जा सकता है। मैं एक अच्छी संतुलन के लिए प्रयास करता हूं। लेकिन जब भी मुझे संदेह होता है; मैं इसे एक निजी विधि के रूप में निकालने के लिए।
बस एक गूंगा अनुमान है, लेकिन मैं कहूंगा कि अधिकांश निजी तरीकों को औसत वर्ग में केवल कुछ स्थानों में बुलाया जाता है। हालांकि ऊपर वर्णित अनुसार, यदि आप लॉजिकल ब्लॉक में सभी कार्यक्षमता तोड़ते हैं तो यह आपके कोड को अधिक पढ़ने योग्य और परीक्षण करने में आसान बनाता है।रिफैक्टरिंग एक अच्छी आदत है
आपको अन्य जगहों का उपयोग करते समय अपने एपीआई & विधियों/गुणों के डिज़ाइन के आधार पर निजी रूप से रिफैक्टर करना चाहिए। आपको यह तय करने के लिए उपयोग नहीं करना चाहिए कि यह निजी/सार्वजनिक बनाना है या नहीं।
कुछ अमूर्त आदर्श में कोई टिप्पणी नहीं होगी। या तो वह, या आपकी * कमेंटरी * कोड एला न्यूथ के लिटरेट प्रोग्रामिंग होगा। –