कक्षा परिभाषा ब्रेक से पीछे संगतता से अंतिम को हटा सकते हैं?

Question

मैं वर्तमान में जोशुआ ब्लोच द्वारा प्रभावी जावा पढ़ रहा हूं और आइटम 17 'विरासत के लिए डिज़ाइन और दस्तावेज़ है या अन्यथा इसे प्रतिबंधित करता है'। लेखक डिफ़ॉल्ट रूप से विरासत को प्रतिबंधित करने का सुझाव देते हैं।

डिफ़ॉल्ट रूप से कक्षाएं अंतिम घोषित करना सुरक्षित है और बाद में रिलीज में कक्षा का विस्तार करने की आवश्यकता होने पर अंतिम कीवर्ड को हटा दें? क्या यह पिछले संस्करण के साथ संकलित कोड के खिलाफ पिछड़ा संगतता तोड़ देगा?

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

Answer 1

यह न तो बाइनरी और न ही स्रोत संगतता को तोड़ता है। क्लास फाइनल बनाने का एक अच्छा विचार यही कारण है; इसके बारे में अपना मन बदलना हमेशा ठीक है। एक वर्ग है कि घोषित किया गया था final अब final घोषित करने की पहले से मौजूद binaries के साथ संगतता को नहीं तोड़ता है बदलने

:

The Java Language Specification, §13.4.2, दोहरी संगतता के बारे में कहने के लिए निम्न है।

मैं आप अभी भी एक अर्थ लगाया उदाहरण है, जहां यह वास्तव में एक कार्यक्रम को तोड़ सकते थे अप कर सकता है लगता है; final वर्ग से विरासत में प्राप्त वर्ग को बाइटकोड-जनरेट करना, और फिर उस जेनरेट क्लास को लोड करना और VerifyError प्राप्त करने पर निर्भर होना।

Answer 2

इस पर मेरे विचार:

एक वर्ग पर final निकाला जा रहा है तत्काल समस्याओं का कारण नहीं होगा। लेकिन इस पर विचार करें:

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

फिर उसके पास आपकी कॉमिकस्ट्रिप प्रिंटर क्लास एडम्स फैक्ट्री के बजाय स्कॉटफैक्टरी का उपयोग करती है। कुछ तोड़ने के लिए बाध्य है।

हमें वापस लाता है कौन क्या यहोशू ब्लॉक कहते हैं:

आप विरासत इरादा है: यह विवेचना के साथ डिजाइन, और यह दस्तावेज़। यदि आप विरासत का इरादा नहीं रखते हैं, तो इसे रोकें।

मुझे उम्मीद है कि मैंने जो कहा वह एक बड़ा लोड-ए-बकवास नहीं था।

---

संपादित करें:

preface of Java Langauge Specification जाएँ, और यहोशू बलोच :) के लिए खोज

Answer 3

आप जावा मानक API जैसी कोई चीज़ को डिजाइन कर रहे हैं, कि प्रोग्रामर के लाखों कई वर्षों के लिए प्रयोग करेंगे, तो हाँ , यहोशू ब्लोच की तरह सोचो। फॉरवर्ड इवोल्यूशन महत्वपूर्ण है।

99% जावा प्रोग्राम नहीं हैं। वे आंतरिक उपयोग के लिए विकसित किए जाते हैं, एपीआई परिवर्तन का प्रभाव छोटा होता है, आमतौर पर सभी स्रोत कोड रिफैक्टरिंग के लिए उपलब्ध होते हैं।ऐसे कार्यक्रमों के लिए सरलता महत्वपूर्ण है। यदि आपके पास जटिल और फैंसी डिज़ाइन हैं, या आप अपना पूरा समय अंतिम के बारे में सोचते हैं या नहीं, तो आप समय बर्बाद कर रहे हैं।

मैंने यहोशू को उनके सुझावों के लिए उचित अस्वीकरण सेट करने के लिए दोषी ठहराया।