क्या यह अनिवार्य उपयोगिता वर्ग अंतिम और निजी कन्स्ट्रक्टर होना चाहिए?

Question

निजी कन्स्ट्रक्टर बनाने से, हम तुरंत बाहर से कहीं भी कक्षा से बच सकते हैं। और कक्षा फाइनल बनाकर, कोई अन्य वर्ग इसे बढ़ा सकता है। कक्षा के लिए private कन्स्ट्रक्टर और final कक्षा के लिए क्यों आवश्यक है?

Answer 1

बनाने के लिए यह दृश्य या जावा के कार्यात्मक बिंदु से एक जनादेश नहीं है जरूरत नहीं थी जटिलता या रनटाइम। हालांकि, व्यापक कोड द्वारा स्वीकार किए गए कोडिंग मानक। यहां तक ​​कि बहुत से स्थिर कोड समीक्षा उपकरण जैसे checkstyle और कई अन्य जांच करते हैं कि इस तरह के वर्गों का यह ध्यान है।

इस सम्मेलन का पालन क्यों किया जाता है, पहले से ही अन्य उत्तरों में समझाया गया है और यहां तक ​​कि ओपी भी शामिल है।

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

1. रखें शिक्षित लोगों को यह का दृष्टांत नहीं है -: वस्तु बनाने से बचने के लिए, हम 3 विकल्प हैं। (कोई साधु व्यक्ति इसे नहीं कर सकता है।)
2. मार्क क्लास सार के रूप में: - फिर से रोबो-कोडर ऑब्जेक्ट नहीं बनाएंगे। हालांकि, समीक्षा और व्यापक जावा समुदाय का तर्क है कि अमूर्त चिह्नों का अर्थ है कि आप चाहते हैं कि कोई इसे विस्तारित करे। तो, यह भी अच्छा विकल्प नहीं है।
3. निजी निर्माता: - संरक्षित फिर से बच्चे वर्ग को ऑब्जेक्ट बनाने की अनुमति देगा।

अब, फिर से अगर किसी को इन उपयोगिता वर्ग के लिए कुछ कार्यक्षमता के लिए नई विधि जोड़ना चाहता है, वह इसे विस्तार करने के लिए, वह नई विधि जोड़ सकते हैं के रूप में प्रत्येक विधि indepenent है और अन्य कार्यक्षमताओं को तोड़ने का कोई मौका नहीं की जरूरत नहीं है । तो, इसे ओवरराइड करने की कोई ज़रूरत नहीं है। और आप भी instiantiate नहीं जा रहे हैं, तो इसे subclass करने की जरूरत है। इसे अंतिम रूप से चिह्नित करने के लिए बेहतर है।

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

Answer 2

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

Answer 3

डिफ़ॉल्ट रूप से वर्ग इस तरह सामान्य रूप से कुल कार्यों जो अलग करना प्रयोग किया जाता है इस, उस मामले में हम एक नई वस्तु

Answer 4

जावा भाषा और जावा रनटाइम के बीच एक महत्वपूर्ण अंतर है।

जब जावा वर्ग बाईटकोड को संकलित किया गया है, वहाँ पहुँच प्रतिबंध, public, package, protected, private बराबर हैं की धारणा नहीं है। private कन्स्ट्रक्टर का आह्वान करने के लिए प्रतिबिंब या बाइटकोड मैनिपुलेशन के माध्यम से यह हमेशा संभव है, इसलिए जेवीएम उस क्षमता पर भरोसा नहीं कर सकता है।

final दूसरी तरफ, बाइटकोड के माध्यम से जारी रहता है, और यह गारंटी प्रदान करता है कि इसे अधिक कुशल बाइटकोड उत्पन्न करने के लिए जावैक द्वारा और जेवीएम द्वारा अधिक कुशल मशीन निर्देश उत्पन्न करने के लिए उपयोग किया जा सकता है।

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