जावा में `शून्य` विधियाँ क्यों हैं?


51

जावा को voidविधियों की आवश्यकता क्यों है ? संदर्भ :

कोई भी विधि घोषित शून्य मान वापस नहीं करती है।

जहां तक मुझे लगता है कि कर सकते हैं, के हर उपयोग voidबेहतर प्रतिष्ठा का झंडा लौटने से सेवा की जाएगी, वस्तु लागू किया जा रहा है, या null

यह हर कॉल को एक स्टेटमेंट के रूप में बताता है जो कि असाइन करने योग्य है, और बिल्डर पैटर्न और मेथड चेनिंग की सुविधा प्रदान करेगा। वे विधियाँ जो केवल उनके प्रभावों के लिए आह्वान की जाती हैं, आमतौर पर एक बूलियन या एक सामान्य Successप्रकार लौटा देती हैं या विफलता पर एक अपवाद फेंकती हैं।


ताकि हमें उप-पाठ लिखने के लिए एक विशेष वाक्यविन्यास की आवश्यकता न हो। हम एक ही फ़ंक्शन का उपयोग कर सकते हैं।
candied_orange

जवाबों:


158

क्योंकि "इस फ़ंक्शन के सफल होने या विफल होने के बीच एक अंतर है और यह पर्याप्त रूप से आत्म-जागरूक है कि यह अंतर बता सकता है" और "इस फ़ंक्शन के प्रभाव के बारे में कोई प्रतिक्रिया नहीं है।" इसके बिना void, आप सफलता के कोड की अनधिकृत जाँच करेंगे और विश्वास करेंगे कि आप मजबूत सॉफ़्टवेयर लिख रहे हैं, जब वास्तव में आप कुछ भी नहीं कर रहे हैं।


10
लेकिन यह सफल हुआ या असफल, यह एक झंडे को न फेंककर या अपवाद को फेंककर व्यक्त करने के लिए कुछ है। और लौटकर voidइस बारे में कुछ भी नहीं कहता है कि क्या विधि या कार्य स्वयं को उचित रूप से फेंकने के लिए पर्याप्त है।
वोल्कर सेगेल

12
@VolkerSiegel: उत्तर का संदर्भ प्रश्न है। ओपी ने सुझाव दिया कि सभी मामलों में जहां शून्य का उपयोग किया जाता है, इसके बजाय विफलता की सफलता का संकेत देने वाली स्थिति ध्वज को वापस करना चाहिए। उस संदर्भ में शून्य वापस आ रहा है वास्तव में कहते हैं कि फ़ंक्शन का शाब्दिक रूप से वापस लौटने के लिए कुछ भी नहीं है। सफलता को इंगित करने के लिए ऐसे फ़ंक्शन को हमेशा 0 पर वापस लाने के लिए मजबूर करना फ़ंक्शन के उपयोगकर्ताओं को यह विश्वास दिलाएगा कि वे त्रुटि की जाँच कर रहे हैं जब वास्तविकता में वापसी मान हमेशा 0 होता है चाहे सफलता या विफलता की परवाह किए बिना।
स्लीपबेटमैन

19
@VolkerSiegel उन स्थितियों की एक बड़ी संख्या है जहां अपवाद चीजों को करने का सही तरीका नहीं है। वास्तव में मैं इसके अपवाद को गलत से सही होने के लिए कहूंगा- एक अपवाद का मतलब है कि कुछ भयानक हुआ जिसका हिसाब होना चाहिए। एक असफल विफलता का मामला कभी भी अपवाद का उपयोग नहीं करना चाहिए
गैबी सांच

35
@GabeSechan नहीं, यदि इसका अनुबंध पूरा करने में असमर्थ है तो अपवादों को फेंक दिया जाना चाहिए। यदि विधि को एक गैर-संदर्भ की आवश्यकता होती है, लेकिन यह एक हो जाता है, तो एक अपेक्षित विफलता होती है और इसे फेंक देना चाहिए।
एंडी

5
इसे ठीक करने के लिए कई वैकल्पिक वाक्यविन्यास हैं। इसका कारण उन्होंने यह (अजीब) समाधान चुना क्योंकि C इसे नियुक्त करता है।
मार्को वैन डे वोअर्ट

95
  1. क्योंकि C में एक voidप्रकार है, और जावा को C भाषा परिवार के कई सम्मेलनों का पालन करने के लिए डिज़ाइन किया गया था।
  2. ऐसे कई कार्य हैं जो आप नहीं चाहते कि कोई मान लौटाया जाए। आप Successवैसे भी "एक सामान्य प्रकार" के साथ क्या करने जा रहे हैं ? वास्तव में, सफलता को इंगित करने के लिए रिटर्न मान जावा में सी की तुलना में कम महत्वपूर्ण हैं, क्योंकि जावा में विफलता को इंगित करने के अपवाद हैं और सी नहीं करता है।

8
> "क्या आप" वैसे भी एक सामान्य सफलता प्रकार "के साथ क्या करने जा रहे हैं?" - जेनेरिक कोड लिखते समय, एक एकल मान प्रकार (इसे यूनिट प्रकार btw कहा जाता है) बहुत उपयोगी है क्योंकि यह फ़ंक्शन के विशेष मामले को समाप्त कर देता है जो "बस लौटते हैं" लेकिन विशेष रूप से कुछ भी वापस नहीं करते हैं। लेकिन जब जावा पहली बार बनाया गया था, तो इसमें कम अभिव्यंजक प्रकार की प्रणाली (प्रकार के मापदंडों के बिना) भी थी, इसलिए बहुत व्यावहारिक अंतर नहीं थे। और अब इसे बदलने में बहुत देर हो चुकी है। अधिक आधुनिक भाषाओं ने वास्तव में "प्रकार" को छोड़ दिया (वास्तव में यह एक प्रकार भी नहीं है, केवल विधियों के लिए एक विशेष मार्कर है) और इसके बजाय यूनिट प्रकार का उपयोग करें।
सर्ज बोर्स्च

9
@SargeBorsch जावा का Voidप्रकार एक इकाई प्रकार (जैसे जेनरिक के लिए) के रूप में कार्य करता है, हालांकि दुख की बात है, यह अलग है void(साइड नोट: हर बार जब आप पिछले संस्करण में गड़बड़ किए गए प्रकार को ठीक करने के लिए एक नए प्रकार का आविष्कार करते हैं तो कुडली बिल्ली का बच्चा मर जाता है)। यदि कोई यूनिट प्रकारों से परिचित नहीं है, तो यह एक सभ्य परिचय है: en.wikipedia.org/wiki/Unit_type
ओगरे Psalm33

1
@ OgrePsalm33 यह वास्तव में एक इकाई प्रकार के रूप में कार्य नहीं करता है (कम से कम व्यावहारिक साधनों में - एक को अभी भी "वापसी नल" लिखना है; विधि से वापस जाने के लिए जिसमें शून्य रिटर्न प्रकार है, और AFAIK संकलक शून्य संदर्भ के लिए स्टैक के साथ स्थान आवंटित करता है; , इस तथ्य का लाभ उठाते हुए कि यह इन मूल्यों को पढ़ने के लिए व्यर्थ है), इसका उपयोग करने के लिए केवल एक सम्मेलन है जहां "उचित" इकाई प्रकार अधिक उपयुक्त होगा।
सर्ज बोर्स्च

3
@immibis क्योंकि परिभाषा के अनुसार यूनिट प्रकार का एक मान होना चाहिए, और शून्य का मान नहीं है। हां, इसका उपयोग करना संभव है null(वास्तव में यह एकमात्र विकल्प है), लेकिन अशक्त एक विशेष बात है, जावा में संदर्भ प्रकार का कोई भी मूल्य शून्य हो सकता है (यह भाषा डिजाइन में एक और गड़गड़ाहट है)। और, जैसा कि मैंने पहले कहा था, यदि आप चिह्न के Voidबजाय रिटर्न प्रकार का उपयोग कर रहे हैं, तो voidजावा संकलक आपका मित्र नहीं है।
सर्ज बोर्स्च

5
@SgegeBorsch शून्य का एक मान है, जो है null। तथ्य यह nullहै कि सबसे प्रकार का एक सदस्य Voidएक इकाई प्रकार है कि क्या अप्रासंगिक है ।
user253751

65

मूल कारण है कि भाषा एक है voidप्रकार है, क्योंकि जैसे में C, भाषा के रचनाकारों नहीं अनावश्यक रूप से भाषा की वाक्य रचना जटिल चाहता था प्रक्रिया है और समारोह रास्ते पास्कल किया था।

वह मूल कारण था।

आपके सुझाव:

स्टेटस फ्लैग वापस करना

वह नो-नो है। हम स्टेटस फ्लैग का इस्तेमाल नहीं करते हैं। अगर कुछ गलत होता है, तो हम इसे अपवादों के माध्यम से रिपोर्ट करते हैं।

वस्तु का आह्वान किया जा रहा है

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

वापस लौट आना

यह आपको कुछ वापस करने के रूप में एक विधि घोषित करने के लिए मजबूर करेगा, जब वास्तव में यह कुछ भी वापस नहीं कर रहा है, इसलिए यह किसी को बहुत भ्रमित करेगा जो एक इंटरफ़ेस को देख रहा है जो यह पता लगाने की कोशिश कर रहा है। लोग अनिवार्य रूप से कुछ अन्यथा बेकार वर्ग का आविष्कार करेंगे जो "नो रिटर्न वैल्यू" के लिए खड़ा है ताकि सभी फ़ंक्शंस जिनके पास लौटने के लिए कुछ भी नहीं है, ऐसे वर्ग के लिए एक अशक्त संदर्भ वापस कर सकते हैं। वह क्लूनी होगा। सौभाग्य से, इसका एक समाधान है, इसे कहा जाता है void। और वह आपके प्रश्न का उत्तर है।


3
कृपया "मूल कारण ..." के लिए एक स्रोत प्रदान करें। मेरी जानकारी में असली कारण यह है कि सी को पोर्टेबल असेंबलर के रूप में डिजाइन किया गया था।
थोरबजोरन रावन एंडरसन

6
@ ThorbjørnRavnAndersen क्या आप वास्तव में वास्तव में हैं, मुझे इस दावे के लिए एक स्रोत प्रदान करने के लिए कह रहे हैं कि जावा का सिंटैक्स सी सिंटैक्स से लिया गया है?
माइक नाकिस

3
@ ThorbjørnRavnAndersen ओह, मैं देख रहा हूं, मुझे गलत समझा गया। तो, आप सी के बारे में मेरे दावे के लिए एक स्रोत चाहते हैं, जावा के बारे में नहीं। ठीक है, मुझे क्षमा करें, मेरे पास इसके लिए कोई स्रोत नहीं है। लेकिन मुझे लगता है कि यह स्पष्ट है। (मैं 1987 में पास्कल में प्रोग्राम करता था, जब मैंने सी। को स्विच किया। मेरी अच्छाई, जो कि 30 साल पहले है।)
माइक नाकिस

6
यह स्पष्ट नहीं है। C को लगभग उसी समय पास्कल के रूप में विकसित किया गया था, जो कि ज्यादातर लोगों को पता नहीं था कि इसका अस्तित्व भी नहीं है। कृपया तथ्यों के रूप में मान्यताओं का उल्लेख न करें।
Thorbjørn रेवन एंडरसन

12
असली मूल कारण यह है कि द्वारा डिफ़ॉल्ट सी कार्यों लौटे था int, तो एक कीवर्ड बाद कश्मीर एंड आर में जोड़ा गया था 'कोई वापसी प्रकार' से संकेत मिलता है।
user207421

20

कुछ तरीके, जैसे System.out.printlnकुछ भी उपयोगी नहीं लौटाते हैं, लेकिन इस दुष्प्रभाव के लिए विशुद्ध रूप से कहा जाता है। voidसंकलक के लिए और कोड के पाठक के लिए एक उपयोगी संकेतक है कि कोई उपयोगी मूल्य वापस नहीं किया गया है।

साधनों के nullबजाय वापस लौटने से voidआपको बस एक NullPointerExceptionपल मिलेगा जब आप किसी भी चीज़ के लिए इस मूल्य का उपयोग करेंगे। तो आप एक रनटाइम त्रुटि के लिए एक संकलन समय त्रुटि का व्यापार करते हैं जो कि बदतर है। इसके अलावा, आपको रिटर्न प्रकार को परिभाषित Objectकरना होगा, जो भ्रामक और भ्रमित करने वाला होगा। (और चेनिंग अभी भी काम नहीं करेगा।)

स्थिति कोड आमतौर पर त्रुटि स्थितियों को इंगित करने के लिए उपयोग किया जाता है, लेकिन जावा में इस उद्देश्य के लिए अपवाद हैं।

thisस्थिर तरीकों से लौटना संभव नहीं है।

सामान्य Successवस्तु को वापस करने का कोई उपयोगी उद्देश्य नहीं होगा।


1
पूरी तरह से आपके साथ सहमत हूं, सबसे सरल और संक्षिप्त जवाब।
webo80

11

एक कारण यह है कि यह कहना, के अलावा कभी भी वापस करने के लिए भ्रामक हो सकता है null। उदाहरण:

क्या Arrays.sort(a)लौटना चाहिए ?

यदि आप तर्क देते हैं कि aलौटाया जाना चाहिए ताकि कॉल को जंजीर किया जा सके (जो आपके प्रश्न से आपकी प्रतिक्रिया को देखते हुए लगता है), तो यह अब स्पष्ट नहीं है कि वापसी मूल्य मूल वस्तु की प्रतिलिपि है, या मूल वस्तु ही । दोनों संभव हैं। और हाँ, आप इसे प्रलेखन में रख सकते हैं, लेकिन यह पर्याप्त अस्पष्ट है कि आप पहली जगह में अस्पष्टता पैदा न करें।

दूसरी ओर, यदि आप यह तर्क देते हैं कि nullलौटाया जाना चाहिए , तो यह सवाल उठता है कि रिटर्न मूल्य क्या जानकारी संभवतः कॉलर प्रदान कर रहा है, और क्यों प्रोग्रामर को लिखने के लिए मजबूर किया जाना चाहिए return nullजब यह कोई जानकारी नहीं देता है।

और अगर आप कुछ और पूरी तरह से बेतुका लौटाते हैं (जैसे लंबाई a) तो यह सिर्फ उस रिटर्न वैल्यू को वास्तव में भ्रमित करने का उपयोग करता है - बस यह सोचें कि int len = Arrays.sort(a)इसके बजाय कहने के लिए कितना अधिक भ्रमित है int len = A.length!


1
सभी निष्पक्षता में, प्रोग्रामर को लिखना आवश्यक नहीं होगा return null;- जेवीएम बस इतना ही जनादेश दे सकता है कि यदि नियंत्रण स्पष्ट returnया throwकथन के अलावा किसी फ़ंक्शन के अंत में गिरता है , nullतो कॉल करने वाले को वापस लौटा दिया जाता है। IIRC C ऐसा करता है, सिवाय इसके कि रिटर्न वैल्यू उस मामले में अपरिभाषित है (यह उस समय में वापसी मूल्य के लिए उपयोग किए जाने वाले स्थान में जो भी मूल्य होता है) होगा।
एक CVn

2
आपके साहसिक प्रश्न का सही उत्तर है, "एक क्रमबद्ध सरणी"।
ब्रायन बोएचेचर

2
@BryanBoettcher: क्या आपने इसे बाकी नहीं पढ़ा?
मेहरदाद

1
@ मिचेल क्जॉर्लिंग: यह ऐसी त्रुटियों को रोकने के लिए जावा भाषा की एक मौलिक संपत्ति है, अर्थात यदि आप एक returnबयान को भूल जाते हैं तो "अपरिभाषित व्यवहार" नहीं करना चाहिए । इसके बजाय, आपको अपनी गलती के बारे में बताते हुए एक कंपाइलर त्रुटि मिलती है। एक निहित प्रभाव return null;"अपरिभाषित व्यवहार" से बेहतर होगा, लेकिन बहुत कुछ नहीं। यह तभी उपयोगी होगा जब रिटर्न प्रकार का कोई अर्थ न हो, लेकिन कंपाइलर निष्कर्ष कहां से निकालता है, कि रिटर्न वैल्यू का कोई अर्थ नहीं है, जब यह नहीं है void?
होल्गर

2
@ माइकलकॉर्जलिंग: "यदि returnसही मायने में कोई मूल्य नहीं जोड़ा जाता है ...", जैसा कि कहा गया है, संकलक के लिए कोई संकेतक नहीं है कि कोई voidप्रकार नहीं होने पर रिटर्न कोई मूल्य नहीं जोड़ेगा । यह वास्तव में विपरीत है, पहली धारणा यह है कि रिटर्न प्रकार की घोषणा करने वाला एक तरीका returnउस प्रकार के उपयोगी कुछ करना चाहता है । और हमने अभी तक आदिम प्रकारों के बारे में बात नहीं की है, जिनका कोई nullमूल्य नहीं है , इसलिए, संकलक द्वारा इंजेक्ट किए गए किसी भी डिफ़ॉल्ट मूल्य में संभावित उपयोगी रिटर्न मानों की सीमा के साथ संघर्ष होगा।
होल्गर

7

एक लौटना booleanजो हमेशा trueआपके सुझाव के बराबर होता है, न केवल व्यर्थ है (वापसी मूल्य कोई जानकारी नहीं देता है), लेकिन वास्तव में भ्रामक होगा। अधिकांश समय, रिटर्न प्रकारों का उपयोग करना सबसे अच्छा होता है जो केवल उतनी ही जानकारी रखते हैं जितनी वास्तव में उपलब्ध है - यही कारण है कि जावा में आपके पास 4 बिलियन संभव मानों के साथ लौटने के बजाय / के booleanलिए है । इसी तरह, दो संभावित मूल्यों के साथ वापस लौटना जहां केवल एक संभव मूल्य ("सामान्य सफलता") है, भ्रामक होगा।truefalseintboolean

यह अनावश्यक प्रदर्शन ओवरहेड भी जोड़ देगा।

यदि किसी विधि का उपयोग केवल उसके साइड इफेक्ट के लिए किया जाता है, तो वापस लौटने के लिए कुछ भी नहीं है, और रिटर्न प्रकार voidबिल्कुल यही दर्शाता है। अपवादों के माध्यम से संभावित दुर्लभ त्रुटियों का संकेत दिया जा सकता है।

एक चीज़ जो सुधारी जा सकती थी, वह voidएक वास्तविक प्रकार बना रही होगी , जैसे कि स्काला Unit। यह कुछ मुद्दों को हल करेगा जैसे कि जेनेरिक को संभालना।


मजेदार तथ्य: List.addहमेशा लौटता है true, लेकिन यह व्यापक अनुबंध के साथ संगत होने के लिए है Collection.add, इसलिए Set.addवापस आ सकता है trueया false
होल्गर

4

जावा एक अपेक्षाकृत पुरानी भाषा है। और 1995 में (जब इसे बनाया गया था) और इसके तुरंत बाद प्रोग्रामर उस समय के बारे में बहुत चिंतित थे जब एक प्रक्रिया ने प्रोसेसर के साथ-साथ मेमोरी की खपत को नियंत्रित किया। रिटर्निंग शून्य कुछ घड़ी चक्र और एक फ़ंक्शन कॉल से मेमोरी मेमोरी की थोड़ी मात्रा को समाप्त कर देगा क्योंकि आपको स्टैक पर रिटर्न वैल्यू नहीं डालना होगा, और आपको बाद में इसे नहीं निकालना होगा।

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


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

8
@SargeBorsch मुझे 20 साल पहले के एक पुराने प्रोग्रामिंग जोक की याद दिलाता है। "खट खट।" "वहाँ कौन है?" ... ... ... ... बहुत लंबा विराम ... ... "जावा"
Dan Neely

4
@ डैनीलीली और कुछ समय बाद, एक एआई-चालित कार पूरी गति के साथ एक दीवार में दुर्घटनाग्रस्त हो गई, यहां तक ​​कि ब्रेक का उपयोग करने की भी कोशिश नहीं की। यह जावा में लिखा गया था। तो, जावा अब ब्रेक नहीं करता है! (यह रूसी भाषा में एक वाक्य था, इसे अंग्रेजी में बहुत अच्छी तरह से अनुवाद नहीं किया जा सकता है)
सर्ज बोर्स्च

2
@SargeBorsch आपके पास अंग्रेजी वाक्य के रूप में क्या काम करता है, भले ही यह अनुवाद में कुछ बारीकियों को खो गया हो। और वाक्य का अनुवाद करना शायद कविता की तुलना में कठिन है।
डैन नीली

3
अच्छे प्रोग्रामर अभी भी प्रदर्शन और मेमोरी की खपत से चिंतित हैं , जो अनावश्यक रूप से लोगों को आज भी प्रासंगिक कचरा वापस करने के लिए कहता है।
स्किलिविज़

2

मैंने ऐसे तर्क पढ़े हैं जो सुझाव देते हैं कि दूसरे विकल्प (वापसी this) के बजाय दृष्टिकोण होना चाहिए void। यह एक बहुत अच्छा विचार है, लेकिन जावा के निर्माण के समय यह बिल्डर-शैली का दृष्टिकोण लोकप्रिय नहीं था। यदि यह उस समय के रूप में लोकप्रिय था, जैसा कि अब है, तो यह दृष्टिकोण हो सकता है। लौटना nullएक बहुत बुरा विचार है IMO। काश मैं nullभाषा में भी नहीं होता।

अब समस्या यह है कि यदि कोई विधि स्वयं के प्रकार का उदाहरण देती है, तो यह स्पष्ट नहीं है कि वह एक नई वस्तु है या एक ही है। अक्सर यह (या नहीं) बात नहीं करता है, लेकिन दूसरी बार यह मायने रखता है। मुझे लगता है कि भाषा को स्पष्ट रूप thisसे शून्य तरीकों पर वापस लाया जा सकता है । एकमात्र मुद्दा जो मैं उस समय सोच सकता हूं, वह यह है कि यदि बाद में उसी प्रकार की एक नई वस्तु को वापस करने के लिए विधि को बदल दिया गया, तो कोई चेतावनी चेतावनी नहीं होगी, लेकिन शायद यह कोई बड़ी बात नहीं है। वर्तमान प्रकार प्रणाली अब इन प्रकार के परिवर्तनों की परवाह नहीं करती है। यह कैसे विरासत / इंटरफेस के साथ बातचीत करता है, इस पर कुछ विचार करने की आवश्यकता होगी, लेकिन यह पुराने एपीआई को बिना बिल्डर शैली के आसानी से बुलाया जा सकेगा जैसे कि उन्होंने किया था।


2
@ अच्छी बात है, यह स्थैतिक तरीकों पर लागू नहीं होगी।
जिमीजैम

14
@ marisbest2 कौन सा तर्क?
8bittree

3
खैर, अगर nullभाषा का हिस्सा नहीं थे , तो लोग सभी प्रकार के प्रहरी मूल्यों का उपयोग कर रहे होंगे, जिसका अर्थ है "कृपया इस तर्क / वापसी मूल्य को अनदेखा करें, इसमें कोई समझदार मूल्य नहीं है"। इसके साथ समस्या nullयह नहीं है कि केवल यह गलत है कि इसका इस्तेमाल गलत तरीके से किया जाए। मैं दांव लगाना चाहते कि इस समस्या को केवल तभी मानकीकृत अतिरंजित किया जाएगा nullकस्टम समाधान के असंख्य है, जहां प्रत्येक कार्यान्वयन चुपचाप उपयोग अनदेखी, या एक standart नल पॉइंटर एक्सेप्शन के बजाय विशेष अपवाद फेंक, आदि जैसे अलग ढंग से व्यवहार करेंगे के साथ प्रतिस्थापित किया जाएगा
सेमीस्टर

2
@cmaster nullएक उचित वैकल्पिक प्रकार है (जैसे Maybeहास्केल में)। जावा में नल के साथ समस्या यह है कि तुरंत कोई निर्णय लेने का कोई तरीका नहीं है कि मूल्य अभ्यास में अशक्त है या नहीं। यह दोनों की ओर जाता है: अनावश्यक रूप से रक्षात्मक प्रोग्रामिंग (नल की जाँच करना जहाँ यह व्यर्थ है, जिससे कोड में वृद्धि का प्रतिशत बढ़ जाता है), और उत्पादन में आकस्मिक एनपीई (यदि यह जाँच करना भूल गया कि इसकी आवश्यकता कहाँ थी)। हाँ, यह आंशिक रूप से एनोटेशन द्वारा हल किया गया है, लेकिन वे वैकल्पिक हैं, हमेशा चेक नहीं किए जाते हैं, आदि। इसलिए वे आपको तीसरे पक्ष के कोड के साथ सीमाओं पर नहीं बचाएंगे।
सर्ज बोर्स्च

2
@SargeBorsch मैं इससे सहमत हूं कि :-) मेरी आपत्ति एक भाषा के खिलाफ है, "कृपया इस मान को अनदेखा करने" के मानक तरीके के बिना। nullइसके लिए ठीक काम करता है (ठीक = सरल), लेकिन ठोस शब्दार्थ के साथ मानकीकृत वैकल्पिक मान निश्चित रूप से एक और अच्छा विकल्प है (ठीक = सुरक्षित)।
सेमीस्टर

2

एक और पहलू:

जावा काफी सख्त विशेषताओं के साथ एक स्थिर भाषा है। इसका मतलब यह है कि कई चीजें जो अन्य भाषाओं (सी / एफ रूबी, लिस्प आदि) में काफी खुली या गतिशील होंगी, सख्ती से निर्धारित की जाती हैं।

यह एक सामान्य डिजाइन निर्णय है। "क्यों" का जवाब देना मुश्किल है (अच्छी तरह से, क्योंकि भाषा के डिजाइनरों ने सोचा कि यह अच्छा होगा!)। "क्या" के लिए बहुत स्पष्ट है: यह संकलक को बहुत सारी त्रुटियों का पता लगाने देता है , जो आमतौर पर किसी भी भाषा के लिए एक बहुत अच्छी सुविधा है। दूसरे, यह भाषा के बारे में तर्क करने के लिए तुलनात्मक रूप से आसान बनाता है। उदाहरण के लिए, जावा भाषा की औपचारिक शुद्धता (उपसमुच्चय) में सिद्ध करना अपेक्षाकृत आसान है; तुलना के रूप में, रूबी एट अल जैसी गतिशील भाषा में यह लगभग असंभव होगा।

यह सोच, भाषा को अनुमति देती है, उदाहरण के लिए, संभावित अपवादों की लागू घोषणा जो एक विधि को फेंक सकती है, अस्पष्ट एकाधिक वंशानुक्रम से बचने के लिए interfaceबनाम classका अलग प्रकार , और इसी तरह। यह क्या है (संकलन समय त्रुटि से निपटने पर मजबूत ध्यान देने के साथ एक स्थिर अनिवार्य OOP वास्तविक दुनिया की भाषा) उन चीजों को वास्तव में काफी सुंदर और शक्तिशाली हैं। वे सैद्धांतिक (विज्ञान) भाषाओं के करीब आते हैं, जो उद्देश्यपूर्ण रूप से सिर्फ किसी भी अन्य वास्तविक दुनिया की भाषा (उस समय, आपके दिमाग में) की तुलना में इनमें से कुछ मुद्दों का पता लगाने के लिए बनाई गई हैं।

इसलिए। एक सख्त voidप्रकार होना एक स्पष्ट संदेश है: यह विधि कुछ भी नहीं लौटाती है, अवधि। यह है जो यह है। हमेशा कुछ वापस करने के लिए प्रवर्तन द्वारा इसे प्रतिस्थापित करने से या तो बहुत अधिक गतिशील व्यवहार हो सकता है (जैसे कि रूबी में जहां हर डीप में एक स्पष्ट या निहित वापसी मूल्य होता है, हमेशा), जो कि अस्थिरता और तर्क के लिए बुरा होगा; या यहाँ कुछ अन्य तंत्र का उपयोग करके बड़े पैमाने पर ब्लोट के लिए।

(और एनबी, रूबी (उदाहरण के लिए) इसे अलग तरीके से संभालती है, और इसका समाधान अभी भी जावा के रूप में बिल्कुल स्वीकार्य है , क्योंकि इसमें एक पूरी तरह से अलग दर्शन है। उदाहरण के लिए यह एक बड़ा ध्यान केंद्रित करते हुए खिड़की से पूरी तरह से बाहर निकलना और तर्कशीलता फेंकता है। भाषा की अत्यधिक उच्च अभिव्यक्ति।)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.