अपनी कोटलिन लाइब्रेरी को चमकदार बनाने के 7 टिप्स

प्रस्तावना

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

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

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

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

1. विस्तार कार्य

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

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

2. डिफ़ॉल्ट तर्क मान

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

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

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

3. वस्तु

क्या आपने कभी जावा में स्वयं सिंगलटन पैटर्न को लागू किया है? आपके पास शायद था और यदि आपको पता होना चाहिए कि यह कभी-कभी कितना बोझिल हो सकता है:

प्रत्येक पेशेवरों और विपक्षों के साथ अलग-अलग कार्यान्वयन हैं। कोटलिन ने एकल संरचना के साथ सिंगलटन पैटर्न कार्यान्वयन के उन सभी 50 रंगों को संबोधित किया, जिन्हें ऑब्जेक्ट घोषणा कहा जाता है। देखो, कोई "डबल-चेकिंग लॉकिंग" नहीं है:

सिंटैक्स के अलावा इसके बारे में क्या अच्छा है कि पहली बार एक्सेस किए जाने पर ऑब्जेक्ट डिक्लेरेशन की इनिशियलाइज़ेशन थ्रेड-सिक्योर और इनिशियलाइज्ड दोनों है।

फैब्रिक, ग्लाइड, पिकासो या किसी अन्य के लिए ऐसी लाइब्रेरी के लिए जो ऑब्जेक्ट के एक एकल उदाहरण का उपयोग करता है, समग्र लाइब्रेरी एपीआई के मुख्य प्रवेश बिंदु के रूप में, यह अब जाने का एक प्राकृतिक तरीका है और पुराने जावा तरीके का उपयोग करने का कोई कारण नहीं है। वही काम करो।

4. स्रोत फ़ाइलें

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

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

लेकिन जब तक आप किसी उपयोगकर्ता को फ़ाइल के आकार से अभिभूत करने के लिए जोखिम में नहीं जाते हैं, तब तक उसे ~ 13.000 पंक्तियों के साथ RecyclerView वर्ग में बदल दें।

5. कोराटाइन

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

लेकिन अब हम कोटलिन के युग में हैं, इसलिए इसे कोरटाइन के उपयोग के पक्ष में डिजाइन किया जा सकता है:

इस तथ्य के बावजूद कि अधिक हल्के होने के मामले में, कोराउटीन पुराने पुराने जावा थ्रेड्स से बेहतर प्रदर्शन करते हैं, वे कोड पठनीयता में महत्वपूर्ण योगदान देते हैं:

6. संविदा

स्थिर coroutines के साथ, Kotlin 1.3 डेवलपर्स को संकलक के साथ बातचीत करने का तरीका भी बताता है। एक अनुबंध एक नई सुविधा है जो हमें पुस्तकालय डेवलपर्स के रूप में एक संकलक के साथ साझा करने की अनुमति देती है जो हमारे पास तथाकथित प्रभाव को निर्दिष्ट करके ज्ञान है। यह समझना आसान बनाने के लिए कि प्रभाव क्या है, आइए जावा से इसकी निकटतम सादृश्यता लाएं। आप में से अधिकांश ने शायद अमरूद से प्रीकॉन्डेन्शन क्लास का उपयोग किया है, जिसमें बहुत सारे दावे हैं और डैगर जैसे पुस्तकालयों में इसका अनुकूलन है, जो पूरी लाइब्रेरी को नहीं लाना चाहते हैं:

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

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

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

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

जैसा कि आपने @ExperimentalContracts एनोटेशन से देखा होगा, कॉन्ट्रैक्ट्स अभी भी प्रायोगिक चरण में हैं, इसलिए न केवल एपीआई समय के साथ बदल सकती है, बल्कि कुछ नई सुविधाएँ भी प्राप्त हो सकती हैं क्योंकि यह अधिक से अधिक परिपक्व हो जाती हैं।

7. जावा इंटरऑपरेबिलिटी

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

पहली बात यह है कि जावा में कोटलिन एक्सटेंशन कार्यों को बदसूरत स्थिर तरीकों में संकलित किया जाएगा जहां विधि का पहला तर्क एक रिसीवर प्रकार है:

जब आपके पास वास्तव में बहुत अधिक नियंत्रण नहीं होता है, तो आप पैकेज स्तर के कार्यों के स्रोत फ़ाइल की शुरुआत में निम्न पंक्ति जोड़कर उत्पन्न वर्ग का नाम कम से कम बदल सकते हैं:

आप किसी उत्पन्न कोड को थोड़ा कैसे प्रभावित कर सकते हैं इसका एक अन्य उदाहरण एक साथी ऑब्जेक्ट विधियों के उपयोग से संबंधित है:

आप कोजलिन को @JvmStatic एनोटेशन का उपयोग करके साथी ऑब्जेक्ट में परिभाषित कार्यों के स्थान पर स्थिर कक्षाएं उत्पन्न करने के लिए बाध्य कर सकते हैं:

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

और अंतिम लेकिन कम से कम जावा उपयोगकर्ताओं के कार्यों में चेक किए गए अपवादों को परिभाषित करने की क्षमता नहीं है, हालांकि वे सीधे कोटलिन में उपलब्ध नहीं हैं। जावा और कोटलिन में अपवाद की घोषणा के प्रतिमान भिन्न होने के बाद से यह आसान हो सकता है:

यहां अधिकांश चीजें वैकल्पिक हैं, लेकिन वे निश्चित रूप से आपके जावा उपयोगकर्ताओं से आपके पुस्तकालय के लिए यश का स्रोत हो सकते हैं।

जमीनी स्तर

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