कोटलिन: शहद के एक बैरल में दो चम्मच टार

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



कोटलिन समुदाय के बारे में उत्साही था, क्योंकि नई प्रोग्रामिंग भाषा जावा की जगह कोड लेखन को सरल बनाती है। यह विशेष रूप से एंड्रॉइड पर ध्यान देने योग्य है, जहां जावा के नए संस्करण दिखाई देते हैं, इसे हल्के ढंग से, "एक क्रेक के साथ"। कई उपकरण लंबी देरी के साथ अपडेट किए जाते हैं, और भी अधिक - उन्हें फर्मवेयर अपडेट बिल्कुल नहीं मिलते हैं। सर्वोत्तम स्थिति में, डिवाइस के लिए समर्थन इसके रिलीज होने के लगभग 2 साल बाद समाप्त होता है, जो एक, अधिकतम दो सिस्टम अपडेट का वादा करता है। हालांकि, लोग उपकरणों का उपयोग करना जारी रखते हैं, जिसका अर्थ है कि डेवलपर्स को दोनों (अब तक) नवीनतम एंड्रॉइड 8, और एंड्रॉइड 5 या पहले के संस्करणों पर भरोसा करना पड़ता है, जहां निश्चित रूप से न केवल नवीनतम, बल्कि जावा का वर्तमान कार्यान्वयन भी है। संदर्भ के लिए, अब एंड्रॉइड 7 और 8 का कुल हिस्सा - वे संस्करण जहां जावा 8 सिस्टम लाइब्रेरी द्वारा समर्थित है - 42.9% है, बाकी जावा 7 है।

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

लेकिन नई भाषा के सभी फायदों के साथ, जिसे हम किसी भी तरह से विवाद में नहीं डालते हैं, विकास प्रक्रिया के दौरान इसमें कुछ नुकसान पाए गए। और आज सहकर्मियों की राय सुनना दिलचस्प होगा कि क्या वे उसी तरह से काम करने में हस्तक्षेप करते हैं जैसे हम करते हैं।

शो नहीं छिपा सकते?

पैकेज, हमेशा की तरह, नामस्थान द्वारा कक्षाओं को व्यवस्थित करने का एक काफी सामान्य तरीका है। लेकिन उनका प्लस केवल यही नहीं है, जावा में वे कक्षाओं और उनके सदस्यों की दृश्यता को सीमित करने के साधन के रूप में भी कार्य करते हैं।

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

जावा 9 ने कोड को मॉड्यूल में तोड़ने की क्षमता का परिचय दिया, और अब कोड के कुछ हिस्से को मॉड्यूल के अंदर हर जगह दिखाई देना संभव है, लेकिन बाहर से नहीं। और यह एक समझदार एपीआई के निर्माण के लिए बहुत उपयोगी है।

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

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

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

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

इसे संसाधित न करें ... भले ही यह आवश्यक हो

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

भाषा के रचनाकार अपने तर्क को इस प्रकार समझाते हैं: यदि हम स्ट्रिंगबर्स्ट का उपयोग करते हैं, तो इसे परिशिष्ट के माध्यम से एक्सेस करते हुए, यह पता चलता है कि हमें IOException को संभालने की आवश्यकता है, भले ही आप सुनिश्चित हों कि यह मूल रूप से नहीं हो सकता है:

Appendable log = new StringBuilder(); try {    log.append(message); } catch (IOException e) {    // Must be safe } 

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

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

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

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

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

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

हम बदलाव का इंतजार कर रहे हैं ...

अधिकतम जिसे हम एंड्रॉइड के तहत गिन सकते हैं वह है जावा 7 या जावा 8 (लेकिन कुछ सीमाओं और कैविट्स के साथ), जबकि जावा 11 पहले से ही आ रहा है। कोटलिन का उपयोग करना, एंड्रॉइड पर प्रोग्रामिंग करना बहुत आसान है, पाठ की लाइनों की संख्या कम हो जाती है ।

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