🤙 ◽️ 🐅 कोटलिन में एक्सटेंशन। खतरनाक नास्तिकता या एक उपयोगी उपकरण? 👏🏽 🔃 🥚

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

विशेष रूप से मुश्किल भाषा की सुविधाओं के साथ मामला है जो जावा में नहीं हैं। इनमें से एक ठोकर का विस्तार किया गया है।

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

डीटीओ को एक्सटेंशन - डेटा ट्रांसफर ऑब्जेक्ट टेम्पलेट का उल्लंघन

उदाहरण के लिए, एक वर्ग उपयोगकर्ता है

class User(val name: String, val age: Int, val sex: String)

एक डीटीओ काफी! इसके अलावा, कई स्थानों में कोड में, यह निर्धारित करने के लिए एक चेक की आवश्यकता होती है कि उपयोगकर्ता वयस्क है या नहीं। सबसे आसान विकल्प सभी स्थानों में एक स्थिति बनाना है

 if (user.age >= 18) { ... }

लेकिन, चूंकि मनमाने ढंग से ऐसे कई स्थान हो सकते हैं, इसलिए इस जांच को विधि में रखना समझदारी है।
यहां तीन विकल्प हैं:

फन फन एडल्ट (उपयोगकर्ता: उपयोगकर्ता) - उपयोगिता वर्ग में आमतौर पर ऐसे कार्य होते हैं।
उपयोगकर्ता वर्ग के अंदर isAdult फ़ंक्शन डालें
```
 class User(val name: String, val age: Int, val sex: String) { fun isAdult() = age >= 18 } 
```
उपयोगकर्ता के लिए एक आवरण लिखें जिसमें समान कार्य होंगे।

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

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

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

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

 fun User.isAdult() = age >= 18

इस कोड का उपयोग इस प्रकार किया जा सकता है जैसे कि इसे उपयोगकर्ता वर्ग के अंदर घोषित किया गया था:

 if(user.isAdult()) {...}

परिणाम एक काफी सटीक समाधान है, जो कम से कम समझौता के साथ, हमारी जरूरतों को पूरा करता है। यदि हम इस तथ्य के बारे में बात करते हैं कि डीटीओ टेम्पलेट का उल्लंघन किया गया है, तो हम यह याद रखना चाहते हैं कि जावा में यह फॉर्म का एक नियमित स्थिर तरीका होगा:

 public static final boolean isAdult(@NotNull User receiver)

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

एक्सटेंशन विशिष्ट हैं। आप एक्सटेंशन के साथ इकाई के उनके अस्तित्व और भ्रमित करने के तरीकों और क्षेत्रों के बारे में नहीं जान सकते

विचार यह है कि डेवलपर परियोजना में आया था, और एक्सटेंशन में लागू किए गए कोड के आसपास, यह स्पष्ट नहीं है कि कौन सी विधि मूल है और कौन सी एक्सटेंशन विधि है।

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

नीचे हम दो तरीकों को कॉल करने का एक उदाहरण देखते हैं: isAdult विस्तार विधि है, isMale उपयोगकर्ता वर्ग के अंदर सामान्य विधि है। बाईं ओर स्क्रीनशॉट डारुका थीम है, दाईं ओर सामान्य लाइट थीम है।

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

आइडिया विकास का माहौल आपको यह निर्धारित करने में मदद करता है कि कौन सी विधि एक विस्तार है और जो ऑटोकॉम्पलिंग के दौरान मूल है। यह सुविधाजनक है।

खेतों के साथ भी स्थिति ऐसी ही है।

"उपयोगकर्ता के लिए <रूट>" का अर्थ है कि यह एक विस्तार है।

साथ ही, यह तथ्य कि आइडिया एक एक्स्टेंसिबल इकाई के लिए "बाइंड" करता है, विकास में बहुत मदद करता है, क्योंकि ऑटो-पूरा करने के लिए एक्सटेंशन विधियों और फ़ील्ड प्रस्तावित हैं।

पूरे परियोजना में विस्तार बिखरे हुए हैं, एक कचरा कर सकते हैं

हमें परियोजनाओं पर इस तरह की समस्या नहीं है, क्योंकि हम मनमाने ढंग से एक्सटेंशन नहीं डालते हैं और अलग-अलग फाइलों या पैकेजों में सार्वजनिक एक्सटेंशन के साथ कोड निकालते हैं।

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

भाषा के रचनाकारों ने संग्रह के लिए विस्तार विधियों को विकसित करते हुए उन्हें _Collections.kt फ़ाइल में रखा।

यह आमतौर पर कोड को व्यवस्थित करने का मामला है, न कि एक्सटेंशन की समस्या का। जावा में स्थैतिक कार्य, और न केवल स्थिर वाले, विस्तार से कम बेतरतीब ढंग से बिखरे हुए हो सकते हैं।

यूनिट परीक्षण के दौरान विस्तार कार्यों की अनदेखी न करें

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

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

 fun UserComponent.getActiveUsers(): List<Users> = this.getUsers().filter{it.status == “Active”}

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

यह संभव है कि एक्सटेंशन फ़ंक्शन विस्तारित वर्ग के अंदर स्थित समान नाम के फ़ंक्शन के साथ ओवरलैप करता है

हम पहले पैराग्राफ से उदाहरण का उपयोग करके इस मामले पर विचार करेंगे। मान लीजिए कि एक फ़ंक्शन एक्सटेंशन है Adult, जो यह जांचता है कि क्या उपयोगकर्ता एक वयस्क है:

 fun User.isAdult() = age >= 18

उसके बाद, हम उपयोगकर्ता के अंदर एक ही नाम के कार्य को लागू करते हैं:

 class User(val name: String, val age: Int, val sex: String){ fun isAdult() = age >= 21 }

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

ऊपर वर्णित स्थिति से पता चलता है कि विस्तार कार्यों का उपयोग करते समय, वास्तविक समस्याएं पैदा हो सकती हैं।

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

विस्तार एक वर्ग से जुड़ा हुआ है, एक वस्तु नहीं है, और यह भ्रम पैदा कर सकता है

उदाहरण के लिए, पहले पैराग्राफ से उपयोगकर्ता वर्ग पर विचार करें। आइए इसे खोलें और इसके उत्तराधिकारी बनाएं छात्र:

 class Student(name: String, age: Int, sex: String): User(name, age, sex)

हम छात्र के लिए एक्सटेंशन फ़ंक्शन को परिभाषित करते हैं, जो यह भी निर्धारित करेगा कि छात्र वयस्क है या नहीं। केवल छात्र के लिए हम स्थिति बदलते हैं:

 fun Student.isAdult() = this.age >= 16

और अब हम निम्नलिखित कोड लिखते हैं:

 val user: User = Student("", 17, "M")

क्या लौटाएगा user.isAdult ())?
ऐसा लगता है कि टाइप स्टूडेंट और फंक्शन की एक वस्तु को वापस लौटना चाहिए। लेकिन यह इतना आसान नहीं है। एक्सटेंशन क्लास से जुड़े होते हैं, ऑब्जेक्ट पर नहीं, और परिणाम गलत होगा।

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

आउटपुट के बजाय

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

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

एक्सटेंशन आपको तर्क को एक एक्स्टेंसिबल क्लास के संदर्भ में लिखने की अनुमति देता है। इसके लिए धन्यवाद, फ़ील्ड और विस्तार विधियों को पढ़ा जाता है जैसे कि वे हमेशा विस्तारित इकाई में मौजूद थे, जो बदले में, कोड के शीर्ष-स्तरीय समझ में सुधार करता है। जावा में, यह नहीं किया जा सकता है। इसके अलावा, एक्सटेंशन में नियमित कार्यों के समान एक्सेस मॉडिफायर हैं। यह आपको उस कोड के साथ समान कोड लिखने की अनुमति देता है जो किसी विशेष फ़ंक्शन के लिए वास्तव में आवश्यक है।
मैपिंग के लिए विस्तार कार्यों का उपयोग करना सुविधाजनक है, जिसे आपको रोजमर्रा के कार्यों को हल करते समय काफी देखना होगा। उदाहरण के लिए, परियोजना में एक वर्ग UserFromExternalSystem है, जिसका उपयोग किसी बाहरी सिस्टम को कॉल करते समय किया जाता है, और एक्सटेंशन फ़ंक्शन में मैपिंग करना बहुत अच्छा होगा, इसके बारे में भूल जाएं और इसका उपयोग करें जैसे कि यह मूल रूप से उपयोगकर्ता में है।
```
 callExternalSystem(user.getUserFromExternalSystem()) 
```
बेशक, सामान्य विधि द्वारा ही किया जा सकता है, लेकिन यह विकल्प कम पठनीय है:
```
 callExternalSystem(getUserFromExternalSystem(user)) 
```
या ऐसा विकल्प:
```
 val externalUser = getUserFromExternalSystem(user) callExternalSystem(externalUser) 
```
वास्तव में, कोई जादू नहीं होता है, लेकिन ऐसी trifles के लिए धन्यवाद कोड के साथ काम करना अधिक सुखद है।
आइडिया और ऑटो-पूर्ण समर्थन। उपयोगिता वर्गों से विधियों के विपरीत, विकास पर्यावरण द्वारा एक्सटेंशन का अच्छी तरह से समर्थन किया जाता है। स्वतः-पूर्ण होने के साथ, पर्यावरण द्वारा "मूल" कार्यों और क्षेत्रों के रूप में विस्तार की पेशकश की जाती है। यह डेवलपर उत्पादकता में अच्छी वृद्धि की अनुमति देता है।
एक्सटेंशन के पक्ष में तथ्य यह है कि कोटलिन पुस्तकालयों का एक बड़ा हिस्सा एक्सटेंशन के रूप में लिखा गया है। संग्रह के साथ काम करने के लिए कई सुविधाजनक और पसंदीदा तरीके एक्सटेंशन (फ़िल्टर, मानचित्र, और इसी तरह) हैं। आप _Collections.kt फ़ाइल की जांच करके इसे सत्यापित कर सकते हैं।

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

नीचे उन सामग्रियों के लिंक दिए गए हैं जिनका उपयोग इस लेख को तैयार करने के लिए किया गया था:

proandroiddev.com/kotlin-extension-functions-more-than-sugar-1f04ca7189ff - यहां से इस तथ्य के बारे में दिलचस्प विचार लिया जाता है कि, एक्सटेंशन का उपयोग करते हुए, हम संदर्भ के साथ अधिक निकटता से काम करते हैं।
www.nikialeksey.com/2017/11/14/kotlin-is-bad.html - यहाँ लेखक एक्सटेंशन का विरोध करता है और एक दिलचस्प उदाहरण देता है, जिसकी चर्चा ऊपर के बिंदुओं में से एक में की जाती है।
medium.com/@elizarov/i-do-not-see-much-reason-to-mock-extension-functions-7f24d88a188a - विस्तार विधियों के गीलेपन के बारे में रोमन एलिगोवरोव की राय।

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