2015-12-11 16 views
21

मैं एक एसिंक्रोनस विधि लिखना चाहता हूं जो CompletableFuture देता है। भविष्य का एकमात्र उद्देश्य यह है कि जब विधि पूरी हो जाए तो इसका नतीजा न हो। क्या CompletableFuture<Void> या CompletableFuture<?> वापस करना बेहतर होगा? क्या एक या दूसरे को पसंद करने का कोई कारण है, या वे एक दूसरे के बदले हैं?रिटर्न CompletableFuture <Void> या CompletableFuture <?>?

  • CompletableFuture अपने कई तरीकों से CompletableFuture<Void> लौटाता है।
  • java.nioFuture<Void>AsynchronousSocketChannel: Future<Void> connect(SocketAddress remote) में है।
  • दूसरी ओर, java.util.concurrent कक्षाएं और ScheduledExecutorService वापसी Future<?>: उदाहरण के लिए, Future<?> submit(Runnable task) के साथ।

ध्यान दें कि मैं केवल वापसी प्रकार, पैरामीटर सूचियों, परिवर्तनीय घोषणाओं या अन्य संदर्भों के बारे में नहीं पूछ रहा हूं।

+1

मुझे भविष्य स्पष्ट लगता है: यह स्पष्ट रूप से कहता है कि भविष्य कुछ भी नहीं है। भविष्य कहता है कि यह अज्ञात कुछ का भविष्य है। –

+3

जावा 6 के बारे में जावा 7 परिवर्तन के बारे में टिप्पणी देखें, [यहां] (http://stackoverflow.com/a/12962219/438154)। –

उत्तर

6

CompletableFuture<Void> का उपयोग करना सबसे अच्छा है।

According to this answerSotirios Delimanolis, Future<?> द्वारा पाया गया एक मामूली एपीआई दोष है। जावा 6 में submit() विधि ने आंतरिक रूप से Future<Object> का उपयोग किया, और इसलिए इसका रिटर्न प्रकार Future<?> पर सेट किया गया था। जावा 7 में कार्यान्वयन को Future<Void> आंतरिक रूप से उपयोग करने के लिए बदल दिया गया, लेकिन एपीआई को बदलने में बहुत देर हो गई, इसलिए वापसी मूल्य Future<?> के रूप में रहा।

नए जावा एपीआई Future<Void> और CompletableFuture<Void> का उपयोग करते हैं। वे उदाहरण हैं जिन्हें हमें पालन करना चाहिए।

12

बेहतर होगा CompletableFuture < शून्य > या CompletableFuture < वापस जाने के लिए? >

क्या एक या दूसरे को प्राथमिकता देने का कोई कारण है, या वे विनिमेय हैं?

तीन संदर्भों जो कोड को प्रभावित कर सकते हैं:

  • रनटाइम - जेनरिक उस पर कोई निहितार्थ है।
  • संकलन - मैं ऐसी स्थिति की कल्पना नहीं कर सकता जहां कुछ विधि Future<Void> स्वीकार करेगी लेकिन Future<?> स्वीकार नहीं करेगी।
  • विकास - यदि Future के नतीजे का कोई अर्थ नहीं है, तो घोषणाओं के माध्यम से उपयोगकर्ताओं के बारे में यह कहना एक अच्छा अभ्यास है।

तो Future<Void> अधिक बेहतर है।

7

CompletableFuture एपीआई को देखते हुए आपको लगता है कि CompletableFuture<Void> तरीकों जहां परिणाम प्राप्त नहीं किया जा सकता है के दुष्प्रभाव प्रकार के साथ प्रयोग किया जाता है (क्योंकि यह अस्तित्व में नहीं है) मिल जाएगा, उदाहरण के लिए:

CompletableFuture.runAsync(Runnable runnable); 

एक लौटने CompletableFuture<Object> यहां भ्रमित हो जाएगा क्योंकि वास्तव में कोई परिणाम नहीं है, हम केवल पूरा होने की परवाह करते हैं। Consumers और RunnablesCompletableFuture<Void> पर वापस आने वाले तरीके, पूर्व: thenAccept, thenAcceptAsyncConsumer और Runnable सामान्य रूप से दुष्प्रभावों के लिए उपयोग किया जाता है।

Void के लिए एक अन्य उपयोग केस तब होता है जब आप वास्तव में परिणाम नहीं जानते हैं। उदाहरण के लिए: CompletableFuture.allOf, उत्तीर्ण सूची एक पूर्णतया भविष्य हो सकती है जो एक रननेबल से उत्पन्न होती है, इसलिए हम परिणाम नहीं प्राप्त कर सकते हैं।

यह सब कहकर, CompletableFuture<Void> केवल तभी अच्छा है यदि आपके पास कोई अन्य विकल्प न हो, यदि आप परिणाम वापस कर सकते हैं तो कृपया इसके लिए जाएं, कॉलर रुचि नहीं ले सकता है अगर वे रुचि नहीं रखते हैं। आपने कहा कि आप केवल पूरा होने में रूचि रखते हैं, फिर हां, CompletableFuture<Void> नौकरी करेगा, लेकिन यदि आपके एपीआई उपयोगकर्ता आपको नफरत करेंगे तो CompletableFuture<T> एक विकल्प था और आपने अभी उनकी ओर से फैसला किया कि उन्हें कभी भी परिणाम की आवश्यकता नहीं होगी।

3

उपयुक्त प्रकार इसके अर्थात् पर निर्भर करता है। सभी सूचीबद्ध विकल्प पूर्ण होने के संकेत देने का वादा करते हैं और असीमित रूप से अपवाद वापस कर सकते हैं।

  • CompletableFuture<Void>: Void उपयोगकर्ता बताता है वहाँ उम्मीद की जा करने के लिए कोई परिणाम है।
  • CompletableFuture<?>? का अर्थ है कि शामिल मान का प्रकार इस अर्थ में अपरिभाषित है कि कोई भी मूल्य वितरित किया जा सकता है।

CompletableFuture कक्षा CompletionStage से कई सुविधा विधियों को प्राप्त करती है। लेकिन यह आपकी विधि के कॉलर को भविष्य के पूरा होने को ट्रिगर करने की अनुमति देता है जो गलत लगता है क्योंकि आपकी विधि स्वयं को पूरा करने के लिए ज़िम्मेदार है। cancel(...) विधि भी है जो CompletableFuture के डिफ़ॉल्ट कार्यान्वयन में काफी व्यर्थ है क्योंकि यह निष्पादन को रद्द नहीं करता है।

  • Future<Void>: Void उपयोगकर्ता बताता है वहाँ उम्मीद की जा करने के लिए कोई परिणाम है।
  • Future<?>? का अर्थ है कि शामिल मान का प्रकार इस अर्थ में अपरिभाषित है कि कोई भी मूल्य वितरित किया जा सकता है।

FutureCompletionStage से सुविधा विधियों की कमी है। यह भविष्य के पूरा होने की अनुमति नहीं देता है लेकिन निष्पादन रद्द किया जा सकता है।

अगला विकल्प CompletionStage<Void> है:

  • CompletionStage<Void>: Void उपयोगकर्ता बताता है वहाँ उम्मीद की जा करने के लिए कोई परिणाम है। हैंडलर को बांधने के लिए सुविधा विधियां मौजूद हैं लेकिन cancel(...) विधि नहीं है। आपकी विधि का कॉलर CompletionStage के समापन को ट्रिगर नहीं कर सकता है।
  • <CancellableFuture extends Future<Void> & CompletionStage<Void>>: Future<Void> और CompletionStage<Void> से विधियों का सेट। यह बताता है कि कोई परिणाम नहीं है, सुविधा विधियां मौजूद हैं और साथ ही रद्द करने का विकल्प भी मौजूद है।आपकी विधि का कॉलर CompletionStage के समापन को ट्रिगर नहीं कर सकता है।

cancel(...) विधि की अनुपस्थिति आपके परिदृश्य में फिट हो सकती है या नहीं। इसलिए यदि आपको रद्दीकरण की आवश्यकता नहीं है और <CancellableFuture extends Future<Void> & CompletionStage<Void>> का उपयोग करें, तो आपको CompletionStage<Void> के साथ जाने का सुझाव है यदि आपको निष्पादन रद्द करने का विकल्प चाहिए। यदि आपने <CancellableFuture extends Future<Void> & CompletionStage<Void>> चुना है तो संभवतः आप Future<Void> और CompletionStage<Void> से प्राप्त होने वाले इंटरफ़ेस को अपने विधि घोषणा में लंबे प्रकार के चौराहे को सीधे डालने के बजाय रिटर्न प्रकार के रूप में उपयोग करने के लिए प्राप्त करना चाहते हैं।

कॉलर के भविष्य को पूरा करने की संभावना के कारण आपको घोषित रिटर्न प्रकार CompletableFuture के साथ लौटने से बचना चाहिए। ऐसा जानबूझकर भ्रमित कोड और आश्चर्यजनक लटकता है क्योंकि यह स्पष्ट नहीं है कि कौन सा कोड अब पूरा होने के लिए ज़िम्मेदार है। टाइप सिस्टम को आपकी विधि के कॉलर द्वारा ट्रिगर करने के अनजाने पूर्ण होने से रोकने के लिए उल्लिखित अधिक प्रतिबंधित प्रकारों में से एक का उपयोग करें।

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