जावा: स्टेटिक क्लास?


130

मेरे पास उपयोगिता कार्यों से भरा एक वर्ग है। इसका एक उदाहरण तात्कालिक बनाना कोई अर्थपूर्ण समझ नहीं है, लेकिन मैं अभी भी इसके तरीकों को कॉल करना चाहता हूं। इससे निपटने का सबसे अच्छा तरीका क्या है? स्थिर वर्ग? सार?


14
आप एक शीर्ष स्तर के वर्ग को स्थिर नहीं बना सकते हैं ...
जॉन

जवाबों:


163

अंतिम के रूप में चिह्नित एक वर्ग पर निजी निर्माणकर्ता और स्थिर तरीके।


19
@matt b: जैसा कि डेविड रॉबल्स अपने जवाब में बताते हैं, आपको क्लास फाइनल करने की जरूरत नहीं है ... यह सबक्लास नहीं किया जा सकता है क्योंकि एक सबक्लास एक सुपर क्लास कंस्ट्रक्टर को इनवाइट करने में असमर्थ होगा क्योंकि यह प्राइवेट है। हालाँकि ... स्पष्ट होने में कोई बुराई नहीं। लेकिन jfyi :-)।
टॉम

93

महान पुस्तक "प्रभावी जावा" के अनुसार :

मद 4: एक निजी कंस्ट्रक्टर के साथ गैरबराबरी को लागू करें

- एक वर्ग को अमूर्त बनाकर गैर-अस्थिरता को लागू करने का प्रयास नहीं करता है।

- एक डिफॉल्ट कंस्ट्रक्टर केवल तभी उत्पन्न होता है जब किसी वर्ग में कोई स्पष्ट कंस्ट्रक्टर नहीं होता है, इसलिए किसी निजी डिस्ट्रक्टर को शामिल करके एक वर्ग को गैर-परिवर्तनीय बनाया जा सकता है:

// Noninstantiable utility class
public class UtilityClass
{
    // Suppress default constructor for noninstantiability
    private UtilityClass() {
        throw new AssertionError();
    }
}

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

साइड इफेक्ट के रूप में, यह मुहावरा भी वर्ग को उपवर्गित होने से रोकता है। सभी कंस्ट्रक्टरों को सुपरक्लास कंस्ट्रक्टर को स्पष्ट रूप से या निहित रूप से लागू करना होगा, और एक उपवर्ग में कोई सुपरक्लास कंस्ट्रक्टर नहीं होगा।


1
क्यों आप चुनते था AssertionErrorजैसे अन्य विकल्पों से अधिक IllegalStateException, UnsupportedOperationException, आदि?
पचेरियर

@Pacerier देखें इस
bcsb1001

@ bcsb1001, जो हमें इस पर लाता है ।
पचेरियर

21

लगता है कि आपके पास java.lang.Math के समान उपयोगिता वर्ग है ।
वहाँ दृष्टिकोण निजी निर्माता और स्थिर तरीकों के साथ अंतिम वर्ग है।

लेकिन यह परीक्षण करने के लिए क्या करता है से सावधान रहें, मैं इस लेख को पढ़ने की सलाह देता हूं
स्टेटिक तरीके डेथ टू टेस्टिबिलिटी हैं


तो java.lang.Math है "परीक्षण के लिए मौत"?
पचेरियर

1
यह कैसे यह स्कोर जब के माध्यम से चलाने को देखने के लिए दिलचस्प हो सकता है code.google.com/p/testability-explorer
क्राउन

6

बस ऊपर की ओर तैरने के लिए, स्थैतिक सदस्य और वर्ग OO में भाग नहीं लेते हैं और इसलिए दुष्ट हैं। नहीं, बुराई नहीं, लेकिन गंभीरता से, मैं एक्सेस के लिए एक सिंगलटन पैटर्न के साथ एक नियमित वर्ग की सिफारिश करूंगा। इस तरह से यदि आपको सड़क के नीचे किसी भी मामले में व्यवहार को ओवरराइड करने की आवश्यकता है, तो यह एक बड़ी वापसी नहीं है। OO आपका मित्र है :-)

मेरी $ .02


17
सिंगलेट्स को भी बुराई माना जाता है।
डेन डायर

3
आप किसी को भी क्लास में तत्काल या उपश्रम करने से रोकने के लिए निजी कंस्ट्रक्टर का उपयोग करते हैं। : डेविड रोबल्स 'जवाब देखें stackoverflow.com/questions/1844355/java-static-class/...
लूटने

5
सिंगलटन निर्भरता इंजेक्शन की तुलना में अधिक दुष्ट नहीं है :)
अप्राप्य

12
OO की अपनी जगह है, लेकिन ऐसे समय होते हैं जब यह सिर्फ व्यावहारिक नहीं होता है, या यह संसाधनों की बर्बादी होगी - उदाहरण के लिए, Math.abs () के रूप में कुछ सरल है। किसी वस्तु को तात्कालिक करने के लिए सिर्फ एक वस्तु को तत्काल करने का कोई कारण नहीं है, जब एक स्थिर विधि कॉल ने आपको बिना किसी ओओ-ओवरहेड के ही सेवा दी होगी। ;)
लूटने

2
@rob फिर ऊ, मैं सहमत हूँ, Math.Abs ​​शायद कभी एक उदाहरण की जरूरत है। जब मैं सुनता हूं "मेरे पास एक उपयोगिता वर्ग है", तो मैं Math.Avg () देखता हूं, जहां अब आपको एक भारित औसत के लिए समर्थित जोड़ने की आवश्यकता है। मुझे एक Url जनरेटर दिखाई दे रहा है, जिसमें param in, url है जिसे href, या url आदि का समर्थन करने के लिए रिफैक्ट करने की आवश्यकता है। इन कारणों से, OO आधारित उपयोगिता वर्ग के पास वापस भुगतान कर सकते हैं। इसके अलावा, अब मैं मानक OO रक्षात्मक रणनीति, परीक्षण छोड़ दूँगा! / मुझे बतख
बेनेट डिल

3

"निजी कंस्ट्रक्टर" तर्कों पर टिप्पणी: चलो, डेवलपर्स बेवकूफ नहीं हैं; लेकिन वे आलसी हैं। एक वस्तु का निर्माण तो स्थिर तरीकों को कहते हैं? होने वाला नहीं।

यह सुनिश्चित करने के लिए बहुत अधिक समय खर्च न करें कि आपकी कक्षा का दुरुपयोग नहीं किया जा सकता है। अपने सहयोगियों के लिए कुछ विश्वास रखें। और हमेशा अपनी कक्षा का दुरुपयोग करने का एक तरीका है कि आप इसे कैसे बचाएं। केवल एक चीज जिसका दुरुपयोग नहीं किया जा सकता है वह एक ऐसी चीज है जो पूरी तरह से बेकार है।


7
ऐसा कोई व्यक्ति जिसने (उत्पादन कोड में, jsut छात्र कोड नहीं) ऑब्जेक्ट को देखा है। ऑब्जेक्टमैथोड मुझे लगता है कि आप जो रैंडम प्रोग्रामर की क्षमताओं को नजरअंदाज करते हैं! :-P
टोफूबीर

2
  • अंतिम वर्ग और निजी कंस्ट्रक्टर (अच्छा लेकिन आवश्यक नहीं)
  • सार्वजनिक स्थैतिक विधियाँ

1

कक्षा को घोषित करने का कोई मतलब नहीं है static। बस इसके तरीकों को घोषित staticकरें और उन्हें सामान्य नाम से जावा के मठ की तरह सामान्य नाम से पुकारें वर्ग ।

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


1
इसके अलावा, एक निजी निर्माता बनाने के लिए मत भूलना।
असफ

@ एसाफ: सहमत। मैंने उस पर अपने जवाब में थोड़ा सा जोड़ा। धन्यवाद।
छिपकली

यदि आप एक आंतरिक वर्ग के भीतर स्थिर तरीके चाहते हैं, तो कक्षा को भी स्थिर होना चाहिए।
रुई मर्क

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.