हम सभी जानते हैं Optional<T> एक विधि T get() है, तो क्यों यह Supplier<T> को लागू नहीं करता है?वैकल्पिक <T> प्रदायक <T> लागू क्यों नहीं करता है?
कोई कारण नहीं है, यह किसी भी पिछले कोड टूट जाएगा अगर ओरेकल यह जावा के भविष्य के संस्करण में लागू करने के लिए थे होने के लिए होता है?
यह क्योंकि वे अलग अलग बातें मतलब है।
एक Optional<T> एक ऐसा तर्क है जो प्रदान किया जा सकता है या नहीं, एक वापसी मूल्य जो प्रदान किया जा सकता है या नहीं, या एक चर जो मूल्य को असाइन किया जा सकता है या नहीं। यदि इसका कोई मूल्य है, तो आप इसे पुनर्प्राप्त करने के लिए .get() का उपयोग कर सकते हैं। .get() एक अपवाद है, तो आप कुछ गलत है, यानी ऐसा, जब मूल्य मौजूद नहीं है, तो आप इसे फेंक सकते हैं।
एक Supplier<T> एक कार्यात्मक उद्देश्य यह है कि मांग पर एक मूल्य (या नल) प्रदान करती है। Optional<T> के विपरीत, यह हर बार जब आप इसे कॉल करते हैं तो एक अलग मूल्य वापस करने के लिए Supplier.get() के लिए उचित है। यदि Supplier.get() अपवाद फेंकता है, तो इसका मतलब है कि इसके कार्यान्वयन में कुछ गड़बड़ हुई, न कि कॉलर ने गलती की।
देखें एक बहुत स्पष्ट और संक्षिप्त उत्तर। – Zhro
@MattTimmermans explains के रूप में, Supplier लागू करने के लिए Optional के लिए कोई तार्किक कारण नहीं है। हालांकि, जावा के विधि संदर्भ समान कार्यात्मक हस्ताक्षर साझा करने वाले इंटरफेस के बीच कनवर्ट करना बहुत आसान बनाते हैं। Optional<T> o को देखते हुए, आप o::get के रूप में Supplier<T> की अपेक्षा किसी भी विधि या चर को पास कर सकते हैं।
java.util.function पैकेज में इंटरफेस में से कोई भी (कम से कम जावा मंच वर्गों में) वर्ग को लागू कर दिया है। मुझे लगता है कि ऐसा इसलिए है क्योंकि इन इंटरफेस को किसी अन्य उद्देश्य के लिए डिज़ाइन नहीं किया गया था, लेकिन पैकेज विवरण के अनुसार, लैम्ब्डा अभिव्यक्तियों और विधि संदर्भों के लिए लक्ष्य प्रकार प्रदान करने के लिए।
यह खाली होने पर 'NoSuchElementException' अपवाद उठाता है; अपनी खाली स्थिति में यह 'प्रदायक' नहीं है। – teppic
आपको 'वैकल्पिक # get()' का उपयोग नहीं करना चाहिए, इसलिए वास्तव में यह एक अच्छी बात है कि यह उस इंटरफ़ेस को लागू नहीं करती है। – Tom
@teppic लेकिन यह एक अनचेक अपवाद है, तो समस्या क्या है? –