2015-09-06 5 views
13

Closeable इंटरफेस जावा 5 में पेश किया गया था जबकि AutoCloseable इंटरफेस जावा 7 में try-with-resources कथन के साथ आया था। Closeable विस्तारित करता है (जावा 7 के बाद से) Autocloseable इंटरफ़ेस।जावा में कैसे है बंद करने योग्य इंटरफ़ेस की नज़दीकी() विधि की idempotence सुनिश्चित किया?

पुस्तक में ओसीए/ओसीपी जावा SE 7 - प्रोग्रामर मैं & द्वितीय अध्ययन गाइड यह पेज 399 पर कहते हैं:

क्या होगा अगर happends हम close() एकाधिक समय कहते हैं? निर्भर करता है। AutoCloseable को लागू करने वाले वर्गों के लिए, कार्यान्वयन को बेवकूफ होना आवश्यक है। जिसका अर्थ है कि आप पूरे दिन close() पर कॉल कर सकते हैं और दूसरी बार और उससे भी कुछ भी नहीं होगा। [...] Closeable को लागू करने वाली कक्षाओं के लिए ऐसी कोई गारंटी नहीं है।

तो इस पाठ के अनुसार, AutoCloseable के कार्यान्वयन idempotent जाने की जरूरत है, और Closeable नहीं के उन। अब जब मैं AutoCloseable interface at docs.oracle.com के प्रलेखन पर एक नजर है, यह कहते हैं:

ध्यान दें कि Closeable की close विधि के विपरीत, ये करीब विधि idempotent किए जाने की आवश्यकता नहीं है। दूसरे शब्दों में, इस close विधि को एक से अधिक बार कॉल करने के लिए कुछ दृश्य दुष्प्रभाव हो सकते हैं, Closeable.close के विपरीत, जिसे एक से अधिक बार बुलाया जाने पर कोई प्रभाव नहीं पड़ता है।

अब यह पुस्तक में जो लिखा गया है उसके विपरीत है। मेरे पास दो प्रश्न हैं:

(1) सही क्या है? Docs.oracle.com या पुस्तक पर डॉक्टर? दो इंटरफेस में से कौन सा बेवकूफता की आवश्यकता है?

(2) कोई फर्क नहीं पड़ता कि किसके लिए बेवकूफ होना चाहिए - क्या मैं सही हूं कि जावा वास्तव में यह सुनिश्चित करने के लिए कोई रास्ता नहीं है कि यह बेवकूफ है? यदि ऐसा है, तो close विधि की "आवश्यकता" idempotent होने की विधि है कि प्रोग्रामर करना चाहिए, लेकिन मैं कभी भी यह सुनिश्चित नहीं कर सकता कि इंटरफ़ेस का उपयोग करने वाले किसी ने वास्तव में ऐसा किया है, है ना? इस मामले में बेवकूफी केवल ओरेकल का सुझाव है, सही?

+0

2) इसका मतलब क्या है: "जावा वास्तव में यह सुनिश्चित करने के लिए कोई रास्ता नहीं है कि यह बेवकूफ है"। भाषा करता है, जैसे अंतिम बुलियन ध्वज संकेत विधि को बुलाया जाता है। दूसरी तरफ, कंपाइलर यह सुनिश्चित करने के लिए निकट कार्यान्वयन के किसी प्रकार का सत्यापन नहीं करता है कि कार्यान्वयन बेवकूफ है। – John

+2

के बारे में (1): पुस्तक में वास्तव में एक गलती है, इस पृष्ठ पर इरेटा पाया गया है जहां इसका उल्लेख है: http://www.coderanch.com/t/641206/ocajp/certification/Errata-OCA-OCP- जावा-एसई –

+0

@ जॉन: मुझे समझ में नहीं आता कि आपका बूलियन ध्वज के साथ क्या मतलब है। मैं पूरी तरह से बेवकूफ संपत्ति के बारे में बात कर रहा हूं। मेरा अनुमान है कि बेवकूफ संपत्ति का सत्यापन नहीं किया जाता है और यहां तक ​​कि ऐसा करना संभव नहीं होगा। –

उत्तर

9
  1. ओरेकल से जावाडोक सही है। बस एक अंतर्ज्ञान क्यों - AutoCloseable वस्तुओं का उपयोग try(){} ब्लॉक में किया जाता है, जहां वास्तव में वास्तव में स्वचालित रूप से कहा जाता है और केवल एक बार; close()Closeable इंटरफ़ेस विधि से आप हमेशा मैन्युअल रूप से कॉल करते हैं और आप इसे दो बार गलती से कॉल कर सकते हैं या अपना कोड पढ़ने में आसान बना सकते हैं। इसके अतिरिक्त - CloseableAutoCloseable बढ़ाता है और से close() विधि के अनुबंध को कमजोर नहीं कर सकता - यह केवल आवश्यकताएं जोड़ सकता है। तो, अमूर्त स्थिति जब AutoCloseable आवश्यक close() बेवकूफ होने और विस्तारित इंटरफ़ेस को रद्द करने के लिए यह आवश्यकता केवल एक खराब डिज़ाइन होगी।

  2. हां, आपकी समझ सही है। यह सिर्फ एक अनुबंध है जिसे प्रोग्रामर को ध्यान में रखना चाहिए। equals() और hashCode() के बीच अनुबंध की तरह। आप इसे एक असंगत तरीके से कार्यान्वित कर सकते हैं और कोई भी आपको नहीं बताएगा। रनटाइम पर आपको बस समस्याएं हो सकती हैं।

+0

मुझे' बराबर() 'और' हैशकोड() 'के साथ तुलना पसंद है। - यह अच्छा है। –

+0

@MathiasBader जानना अच्छा है, धन्यवाद। –

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