क्या क्लास फाइनल बनाने के लिए कोई सामान्य दिशानिर्देश हैं?कक्षा को अंतिम बनाने के लिए परिस्थितियां?
मैंने सोचा था कि अगर आप नहीं चाहते थे कि लोग आपकी कक्षा का विस्तार कर रहे हों, लेकिन यह थोड़ा सा लगता है .... naive ??
क्लास फाइनल बनाना केवल नोट के रूप में इसे विस्तारित होने से रोकता है। आप ऐसा क्यों करना चाहते हो?
एक सामान्य उपयोग केस अपरिवर्तनीयता की गारंटी है। यदि आप एक अपरिवर्तनीय वर्ग तैयार करते हैं लेकिन इसे अंतिम नहीं बनाते हैं, तो इसे एक परिवर्तनीय तरीके से बढ़ाया जा सकता है। यह बदले में एक वर्ग के आविष्कार को दूषित करने या समवर्ती मुद्दों को बनाने के लिए उप-वर्ग का कारण बन सकता है।
आप इस तथ्य को दस्तावेज करने के लिए अंतिम रूप में एक वर्ग को चिह्नित भी कर सकते हैं कि इसे विस्तारित करने के लिए डिज़ाइन नहीं किया गया है। उदाहरण के लिए देखें प्रभावी जावा # 17: "विरासत के लिए डिज़ाइन और दस्तावेज़ या अन्यथा इसे प्रतिबंधित करें"।
यदि फ़ील्ड स्वयं अंतिम हैं, तो यह (सैद्धांतिक रूप से) कोई मुद्दा नहीं है। हालांकि प्रतिबिंब सभी नियमों को तोड़ता है ... – user949300
@ user949300 सहमत हैं, लेकिन एक अच्छा काउंटर उदाहरण बिगडिसीमल है, जो अपरिवर्तनीय है लेकिन अंतिम नहीं है, और इसमें कुछ गैर-अंतिम फ़ील्ड हैं। यह पहली जगह में अंतिम होना चाहिए था। – assylias
@ वासिलियास, हालांकि मैंने आपको चिह्नित किया है, मैं खराब बनाए रखने वाले पुस्तकालयों में अंतिम कक्षाएं देखना पसंद नहीं करता हूं। ऐसा इसलिए है क्योंकि यह कक्षा को विस्तारित करके '@ ओवरराइड' अपमानजनक कोड को कार्यान्वित करने से अपस्ट्रीम उपयोगकर्ताओं (मुझे!) को प्रतिबंधित करता है। यदि पुस्तकालय सक्रिय रूप से बनाए रखा जाता है, तो ब्लोच में यह बिल्कुल सही है। – fommil
यह अच्छी तरह से स्थापित है कि विरासत encapsulation तोड़ता है। एलन स्नाइडर अपने पेपर Encapsulation and inheritance in object-oriented programming languages में देखभाल का प्रदर्शन करता है जो आपको विरासत के साथ व्यायाम करना चाहिए।
जोशुआ ब्लोच अपनी पुस्तक Effective Java में अनुशंसा करता है कि आप अपनी कक्षाओं को विरासत में रखने के लिए डिज़ाइन और दस्तावेज करें या अन्यथा आप इसे प्रतिबंधित करते हैं, जो पहले से ही स्नाइडर को ज्ञात समस्याओं का जिक्र करते हैं।
यदि किसी बिंदु पर आप निश्चित नहीं हैं कि भविष्य में आपकी कक्षाओं को कैसे बढ़ाया जा सकता है या यदि आपके पास वास्तव में विस्तारित होने का कोई इरादा नहीं है, तो आप शायद उन्हें अंतिम बनाने से बेहतर हैं। आप उन्हें बाद में विस्तार के लिए खोल सकते हैं, लेकिन इसके विपरीत (यदि आप खुले सिस्टम का निर्माण कर रहे हैं तो सब से ऊपर) दर्द का असली कारण हो सकता है, यदि परिस्थितियों के आधार पर असंभव नहीं है।
अपने पेपर A Study of the Fragile Base Class में मिखाजलोव और सेकरिंस्की के शोधों का विश्लेषण अनुचित तरीके से विरासत का उपयोग करते समय आपके पास होने वाली समस्याओं की एक श्रृंखला का प्रदर्शन करता है जो आपको एक व्यापक विचार दे सकता है कि यह क्यों महत्वपूर्ण हो सकता है।
आदर्श रूप से, आपने जोश ब्लोच पढ़ा है और पूरी तरह से काम करने वाली विरासत के लिए अपनी कक्षा तैयार की है। लेकिन, व्यावहारिक रूप से, मेरा (आईएमएचओ) एक वर्ग फाइनल बनाने का उत्तर
क्या आप दूसरों को इसका विस्तार करने के लिए भरोसा करते हैं (या चाहते हैं)?
यदि यह String या कुछ सुरक्षा संबंधित वर्ग जैसे सुपर-क्रिटिकल क्लास है, तो निश्चित रूप से इसे अंतिम बनाएं।
यदि आप असली फैंसी सामान कर रहे हैं और कक्षा को उचित रूप से विस्तार करना मुश्किल होगा, पर विचार करें, जो कि कक्षाओं का उपयोग करने वाले लोगों की अपेक्षाओं के आधार पर इसे अंतिम बनाते हैं। यह भी इस बात पर निर्भर करता है कि यह एक सामान्य उद्देश्य पुस्तकालय है या कुछ कंपनी/परियोजना विशिष्ट कोड है, और चाहे यह गिलहरी वीडियो या हृदय गति निर्माता के साथ वेबसाइट के लिए है - यानी, गरीब सबक्लास चीजों को तोड़ने में कितनी बुरी तरह ???
यदि आप यह सब कुछ नहीं कर रहे हैं, तो इसे अंतिम बनाकर उपयोगकर्ताओं को परेशान न करें। मैंने अक्सर Double फ़ाइनल जैसे वर्ग बनाने के लिए जावा को शाप दिया है।
+1 मेरे सैद्धांतिक-हम-एक-परिपूर्ण-दुनिया के उत्तर का असली जीवन समकक्ष ;-) – assylias
@ user949300 खराब सबक्लास चीज़ों को कितनी बुरी तरह से खराब कर देगा? एक बंद प्रणाली में, आप शायद उस कोड में आने वाली किसी भी समस्या को पकड़ सकते हैं जहां कक्षा का उपयोग किया जाता है। एक खुली प्रणाली में यह वर्ग को उचित रूप से ठीक करने के लिए प्रस्तुत कर सकता है, आप शायद उपयोगकर्ताओं को हमेशा के लिए समस्या के साथ रहना पड़ सकता है, क्योंकि वहां हजारों अन्य उपयोगकर्ता टूटी हुई एपीआई के अनुबंध पर भरोसा करते हैं, जिनके पास उपयोगकर्ता हैं कक्षा को बढ़ाया और अपनी त्रुटियों को अभी तक और अधिक एपीआई में प्रचारित किया। –
@EdwinDalorzo OTOH, यदि कक्षा 'अंतिम' है और जो कुछ भी करना चाहती है, उसका अनुमान नहीं लगाता है (जो 100% निश्चित होने वाला है) कार्यवाही ("उपचार") बीमारी से भी बदतर हो सकती है। तो "यह निर्भर करता है"। – user949300
मुझे लगता है कि यहां इस तरह के बहुत सारे प्रश्न हैं: http://stackoverflow.com/questions/2169668/why-would-you-make-a-whole-class-sealed- उदाहरण के लिए उदाहरण –
पर विचार करें कक्षा स्ट्रिंग, यह अंतिम है।इसे अंतिम रखा जाना था और विस्तार की इजाजत नहीं थी क्योंकि जेवीएम स्ट्रिंग-पूल बनाए रखता है, वे अपरिवर्तनीय हैं। अगर कोई इसे ओवरराइड करता है, तो वह जेवीएम के लिए समस्याएं पैदा करेगा, हो सकता है कि यह किसी भी स्ट्रिंग-पूल को बनाए रखने में सक्षम न हो क्योंकि JVM को पता नहीं है कि विस्तारित वर्ग ने कुछ तरीकों को कैसे कार्यान्वित किया है और बड़ी अवांछनीय समस्याएं पैदा कर सकती हैं। तो, यह सब कुछ प्रस्तुत करता है और एक महान डिजाइन निर्णय की आवश्यकता होगी कि कक्षा को अंतिम या नहीं प्रदान करना है या नहीं। हम निश्चित रूप से दिन-दर-दिन आधार पर कक्षाओं के लिए अंतिम उपयोग नहीं करते हैं। – devang
क्या * अन्य * मानदंड संभवतः हो सकता है? – EJP