2011-09-01 11 views
27

मान लें कि मेरे पास उपयोगिता वर्ग दिनांक है (नीचे देखें)। इस विधि का उपयोग करने के लिए एक कॉलर विधि DateUtils.getDateAsString (aDate) का उपयोग करती है। यह बेहतर होगा स्थिर संशोधक एक वसंत सेम दूर करने के लिए और बनाने के DateUtil (देखें DateUtilsBean) और वर्गों बुला को इसकी सुई या बस के रूप में है इसे छोड़?स्प्रिंग एप्लिकेशन में उपयोगिता वर्ग - क्या मुझे स्थिर तरीकों का उपयोग करना चाहिए या नहीं?

एक नुकसान यह है कि मैं स्थिर उपयोग करने के साथ देख सकते हैं मजाक आसपास के मुद्दों, How to mock with static methods?

public class DateUtils { 

    public static String getDateAsString(Date date) {  
     String retValue = "" // do something here using date parameter 
     return retValue; 
    } 
} 

स्प्रिंग बीन संस्करण

@Component 
public class DateUtilsBean { 

    public String getDateAsString(Date date) {  
     String retValue = "" // do something here using date parameter 
     return retValue; 
    } 
} 

उत्तर

21

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

+6

सहमत हुए। सिर्फ इसलिए कि _anything_ _could_ को स्प्रिंग बीन के रूप में वायर्ड किया जाना मतलब नहीं है _everything_ _should_ स्प्रिंग बीन के रूप में वायर्ड किया जाना चाहिए। –

+2

क्या होगा यदि स्थिर विधि कॉन्फ़िगरेशन फ़ाइल पढ़ती है जो मेरे एप्लिकेशन को चलाती है? यह संभावना है कि मैं उस व्यवहार को नकल करना चाहता हूं। बस इसके बारे में सोचें: आप कार्यात्मक परीक्षण करना चाहते हैं लेकिन आप "कॉन्फ़िगरेशन फैक्ट्री" बनना नहीं चाहते हैं। अगर यह एक सिंगलटन होगा तो मैं उस विधि को आसानी से नकल कर सकता हूं और कोड से अपना परीक्षण चला सकता हूं। हालांकि पावरमैक के साथ स्थैतिक तरीकों का नकल करना भी संभव है। – uthomas

+4

यह अति-इंजीनियरिंग हो सकता है, लेकिन इसे एक बीन बनाने के लिए जिसे इंजेक्शन दिया जा सकता है, इकाई-परीक्षण निर्भर वर्गों को आसान बनाता है। अगर यह एक इंटरफ़ेस लागू किया गया था तो यह परीक्षण करना और भी आसान बना देगा। – Behrang

4

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

संक्षेप में, हाँ यह ज्यादातर मामलों में एक बेहतर डिजाइन किया जाएगा। फिर भी, एक मामले में खुलासा के रूप में सरल, यह एक बड़ा अंतर नहीं करता है।

4

मैं शॉन पैट्रिक फ़्लॉइड से सहमत हूं।

यह मेरा मानदंड है: यदि कक्षा के तरीके केवल बाह्य मानदंडों (डेटाबेस, फ़ाइल सिस्टम, उपयोगकर्ता कॉन्फ़िगरेशन, अन्य ऑब्जेक्ट्स/बीन्स इत्यादि) के साथ प्राप्त पैरामीटर पर चीजें करते हैं, तो मैं करूँगा यह स्थैतिक तरीकों के साथ, आमतौर पर एक निजी कन्स्ट्रक्टर के साथ एक अंतिम कक्षा में।

अन्यथा, मैं इसे एक वसंत सेम का उपयोग कर लागू होगा।

तो, मामला यह है कि आप को बढ़ाने में, इस कसौटी के अनुसार, मैं स्थिर तरीकों के साथ एक वर्ग लिखेंगे।

सम्मान।

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