जावा में निजी सहायक उपयोगिता विधियों बनाम निजी सहायक उपयोग विधियां

Question

मेरे पास एक जावा क्लास है जो लंबे समय से हो रही है। जब मैं कोड गुणवत्ता उपकरण के माध्यम से इसे चलाता हूं, तो मुझे कक्षा में लाइनों की संख्या के लिए ध्वजांकित किया जाता है।

यह एक निम्न परत वर्ग है, जो Spring's@Autowired के साथ ऊपरी परतों द्वारा उपयोग किया जाता है। कक्षा में बहुत से निजी उदाहरण विधियां हैं जो स्थैतिक नहीं हैं। वे विधि पैरामीटर पर काम करते हुए, किसी भी इंस्टेंस फ़ील्ड का उपयोग नहीं करते हैं।

क्या मैं कुछ अलग उपयोगिता वर्ग में public static के रूप में इन विधियों को सुरक्षित रूप से स्थानांतरित कर सकता हूं? डाउनसाइड्स क्या हैं?

Answer 1

"गलत" मानसिकता यहां।

आप अपनी कक्षाओं को फिर से काम नहीं करते हैं क्योंकि उपकरण इस या उसके बारे में शिकायत कर रहे हैं।

आप अपने स्रोत कोड के गुणवत्ता को बेहतर बनाना चाहते हैं; और ऐसे उपकरण "सोचने वाले विषयों के बारे में सोचने" के विषयों की पहचान करने में मदद कर सकते हैं। आप उनकी प्रतिक्रिया संकेत के रूप में लेते हैं; "आदेश" के रूप में नहीं।

इसलिए आप कक्षा के भीतर "कोड की रेखाओं" के बारे में चिंता नहीं करते हैं। इसके बजाए, आप इस श्रेणी में जिम्मेदारियों के बारे में चिंता करते हैं। मतलब: रेखा संख्या गिनती एक समस्या नहीं है - लेकिन Single Responsibility Principle के उल्लंघन हैं।

इस प्रकार: आप वापस कदम उठाएं और जांचें कि आपकी कक्षा वास्तव में क्या कर रही है। और जब यह स्पष्ट रूप से एक से अधिक चीजें कर रहा है, तो आप अन्य वर्गों में ऐसे पहलुओं को निकालते हैं!

मतलब: यदि आप वास्तव में पाते हैं कि यह सब कोड उस वर्ग की ज़िम्मेदारी के लिए "संबंधित" है; फिर इसे वहां रखें। असंबद्ध सहायक वर्गों में आंतरिक कार्यान्वयन विवरण डालने शुरू न करें; सिर्फ इसलिए कि कुछ टूल आपको लाइनों की संख्या के बारे में चेतावनी देते हैं।

दूसरी तरफ, निजी विधियों को स्थिर/पैकेज संरक्षित किसी चीज़ में बदलना आपको उन तरीकों का परीक्षण करने की अनुमति देगा। जो एक फायदा हो सकता है। लेकिन जैसा कि कहा गया है: जब तक हम कार्यान्वयन विवरण के बारे में बात कर रहे हैं, उन्हें निजी रहना चाहिए; और वे वैसे भी यूनिट परीक्षण नहीं किया जाना चाहिए।

लंबी कहानी कोड: जानें और समझें कि "साफ कोड" क्या है; और वहां उल्लिखित विचारों का पालन करने का प्रयास करें।

Answer 2

विधियों का विभाजन उद्देश्य/एप्लिकेशन/तर्क (आप इसे नाम दें) द्वारा किया जाना चाहिए, तकनीकी गुणों से नहीं।

एक लंबे स्रोत कोड को शायद कई छोटे आकार के वर्गों में विभाजित किया जा सकता है, प्रत्येक के अपने अलग उद्देश्य/जिम्मेदारी के साथ।

Answer 3

मैं लगातार उपयोगिता कक्षाओं का उपयोग करता हूं जिसमें स्थिर तरीके होते हैं और इसे बहुत सुविधाजनक पाते हैं। यदि विधियां वास्तव में केवल एक वर्ग द्वारा उपयोग के लिए हैं, तो आप अपनी उपयोगिता कक्षा को अपनी मूल कक्षा के भीतर स्थिर निजी कक्षा के रूप में रख सकते हैं। लेकिन मुझे पता चला कि कई मामलों में सामान्य स्थिर उपयोगिता विधियों का उपयोग कई वर्गों द्वारा किया जा सकता है, इसलिए इस मामले में मैं स्थिर विधियों के सेट के साथ एक अलग उपयोगिता वर्ग बना सकता हूं जिसका उपयोग कई वर्गों द्वारा किया जा सकता है।

इसके अलावा, मैं सोच के सामान्य तरीके के संदर्भ में GhostCat के उत्तर से दृढ़ता से सहमत हूं। एक वर्ग के आकार के लिए - यह चिंता का विषय हो सकता है लेकिन आम तौर पर मुझे इसके बारे में चिंता नहीं है। जो मैं वास्तव में देखता हूं वह आपके तरीकों के आकार के लिए है।मुझे अपने नाम और पैरामीटर नाम और ऑर्डर और तर्क के साथ शुरू करने के तरीकों को छोटा और आत्म-स्पष्टीकरण होना पसंद है। यदि आंतरिक तर्क का बड़ा हिस्सा है - इसे अलग विधि में निकालें। यह कोड को बेहतर पठनीय और रखरखाव से बनाता है।

Answer 4

कोड की गुणवत्ता लाइनों की संख्या द्वारा नहीं मापा जा सकता है। यदि आपको लगता है कि कक्षा फ़ाइल दिन-प्रतिदिन बढ़ रही है तो सुनिश्चित करें कि आपकी कक्षा एकल जिम्मेदारी सिद्धांत का पालन करती है।

जब आपकी कक्षा सिद्धांत का पालन नहीं करती है, तो उन्हें अलग-अलग वर्गों में अलग करें और कक्षाओं को पैकेज में बनाएं।

अन्यथा आप अपनी बेस क्लास को abstract class के रूप में बना सकते हैं और abstract के रूप में अपनी उपयोग विधियां बना सकते हैं। एक बच्चा वर्ग है जो बेस क्लास में सार तत्वों के लिए कार्यान्वयन प्रदान करने वाली बेस क्लास को बढ़ाता है।

यहाँ एक अच्छा SO answer on when you could make your methods as static

रूप @Zack Jannsen से कहा है,

"स्थिर" अक्सर मूल्यवान जब आप जानते हैं कुछ उदाहरणों भर में बदलने के लिए नहीं जा रहा है है। यदि ऐसा है, तो मैं वास्तव में "सिंगल उत्तरदायित्व सिद्धांत" पर विचार करता हूं, जिसका अर्थ है कि किसी वर्ग में उत्तरदायित्व होना चाहिए और इस प्रकार बदलने का केवल एक कारण होना चाहिए। मुझे लगता है कि "ConvertMpgToKpl (डबल एमजीपी)" फ़ंक्शन, और समान विधियों को अपनी कक्षा में ले जाने पर विचार करें। कार ऑब्जेक्ट का उद्देश्य कारों के तत्काल होने की अनुमति है, उनके बीच तुलना प्रदान नहीं करता है। जो कक्षा के बाहर होना चाहिए।

हालांकि स्थिर इनपुट तर्क के आधार पर लगातार परिणाम पैदा करता है आप ऑब्जेक्ट निर्माण के बिना विधि का उपयोग, हमेशा जब विधि स्थिर रूप

• विधि बनाने की कोशिश कर निम्न बातें याद करने की अनुमति देता
• आप स्मृति में होने के लिए हमेशा उस विधि की आवश्यकता होती है (यानी; आपको अक्सर विधि की आवश्यकता होती है) - यह एक बड़ी विधि तक पहुंचने के लिए बेहतर हो सकता है जिसे ऑब्जेक्ट सृजन की सहायता से केवल कुछ ही बार उपयोग किया जा सकता है बल्कि static
के माध्यम से इसे एक्सेस करने के लिए
• उपयोगिता विधियों का उपयोग अक्सर static