कोटलिन संदर्भ-उन्मुख प्रोग्रामिंग का परिचय

यह कोटलिन में संदर्भ-उन्मुख प्रोग्रामिंग के लिए एक परिचय का अनुवाद है

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

फ़ंक्शन अनुमतियों के बारे में कुछ शब्द

जैसा कि सर्वविदित है, तीन मुख्य प्रोग्रामिंग प्रतिमान हैं ( पेडेंट का ध्यान दें : अन्य प्रतिमान हैं):

• प्रक्रियात्मक प्रोग्रामिंग
• ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग
• कार्यात्मक प्रोग्रामिंग

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

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग शैली कार्यों के दायरे को सीमित करती है। फ़ंक्शंस वैश्विक नहीं हैं, इसके बजाय वे कक्षाओं का हिस्सा हैं, और केवल इसी वर्ग के उदाहरण पर कॉल किया जा सकता है ( पेडेंट का नोट : कुछ शास्त्रीय प्रक्रियात्मक भाषाओं में एक मॉड्यूलर प्रणाली होती है और इसलिए, गुंजाइश; प्रक्रियात्मक भाषा! = C)।

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

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

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

यह क्या है?

ऑब्जेक्ट एप्रोच के मामले में, जब किसी ऑब्जेक्ट पर एक विधि का आह्वान किया जाता है, तो हमारे पास इसके तर्क होते हैं, लेकिन इसके अलावा हमारे पास एक स्पष्ट (पायथन के मामले में) या एक अंतर्निहित पैरामीटर होता है, जो कॉल क्लास के उदाहरण का प्रतिनिधित्व करता है (इसके बाद सभी उदाहरण Kotlin में लिखे गए हैं):

class A{ fun doSomething(){ println("    $this") } } 

नेस्टेड कक्षाएं और क्लोजर चीजों को थोड़ा जटिल करते हैं:

 interface B{ fun doBSomething() } class A{ fun doASomething(){ val b = object: B{ override fun doBSomething(){ println("    $this  ${this@A}") } } b.doBSomething() } } 

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

और यहाँ कोटलीन है

कोटलिन हमें एक पूरी तरह से नया "खिलौना" देता है - विस्तार कार्य । ( पेडेंट द्वारा नोट : वास्तव में, वे इतने नए नहीं हैं, वे C # में भी मौजूद हैं)। आप प्रोग्राम में कहीं भी ए। एडासोमेस्टिंग () जैसे फ़ंक्शन को परिभाषित कर सकते हैं, न कि केवल ए के अंदर । इस फ़ंक्शन के अंदर, हमारे पास यह पैरामीटर है, जिसे एक रिसीवर कहा जाता है, उदाहरण ए की ओर इशारा करता है जिस पर विधि कहा जाता है:

 class A fun A.doASomthing(){ println(" -   $this") } fun main(){ val a = A() a.doASomthing() } 

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

कोटलिन के पास अगली महत्वपूर्ण चीज रिसीवर के साथ कोड ब्लॉक है। आप प्राप्तकर्ता के रूप में कुछ का उपयोग करके कोड का एक मनमाना ब्लॉक चला सकते हैं:

 class A{ fun doInternalSomething(){} } fun A.doASomthing(){} fun main(){ val a = A() with(a){ doInternalSomething() doASomthing() } } 

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

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

 class B class A{ fun B.doBSomething(){} } fun main(){ val a = A() val b = B() with(a){ b.doBSomething() //   } b.doBSomething() //   } 

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

प्रसंग-उन्मुख स्वभाव

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

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

 val n: Number = 1.0 n + 1.0 //  `plus`     `Number` 

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

 interface NumberOperations{ operator fun Number.plus(other: Number) : Number operator fun Number.minus(other: Number) : Number operator fun Number.times(other: Number) : Number operator fun Number.div(other: Number) : Number } object DoubleOperations: NumberOperations{ override fun Number.plus(other: Number) = this.toDouble() + other.toDouble() override fun Number.minus(other: Number) = this.toDouble() - other.toDouble() override fun Number.times(other: Number) = this.toDouble() * other.toDouble() override fun Number.div(other: Number) = this.toDouble() / other.toDouble() } fun main(){ val n1: Number = 1.0 val n2: Number = 2 val res = with(DoubleOperations){ (n1 + n2)/2 } println(res) } 

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

 fun NumberOperations.calculate(n1: Number, n2: Number) = (n1 + n2)/2 val res = DoubleOperations.calculate(n1, n2) 

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

यह भी याद रखने योग्य है कि संदर्भों को नेस्टेड किया जा सकता है:

 with(a){ with(b){ doSomething() } } 

यह दोनों वर्गों के व्यवहार के संयोजन का प्रभाव देता है, हालांकि, यह सुविधा कई प्राप्तकर्ताओं ( KT-10468 ) के साथ एक्सटेंशन की कमी के कारण आज नियंत्रित करना मुश्किल है।

स्पष्ट कोरआउट्स की शक्ति

एक संदर्भ-उन्मुख दृष्टिकोण का सबसे अच्छा उदाहरण Kotlinx-coroutines पुस्तकालय में उपयोग किया जाता है। विचार का एक स्पष्टीकरण रोमन एलिसैरोव के एक लेख में पाया जा सकता है। यहां, मैं केवल इस बात पर जोर देना चाहता हूं कि कॉरटीनसकोप संदर्भ-उन्मुख डिजाइन का एक मामला है। CoroutineScope दो भूमिकाएँ निभाता है:

• इसमें CoroutineContext शामिल है, जिसे coroutine चलाने के लिए आवश्यक है और एक नया coroutine लॉन्च होने पर विरासत में मिला है।
• इसमें मूल कोराउटीन की स्थिति समाहित है, जो आपको उत्पन्न रद्द करने की अनुमति देता है यदि उत्पन्न कोरआउट एक त्रुटि फेंकता है।

इसके अलावा, संरचित संगामिति संदर्भ-उन्मुख वास्तुकला का एक शानदार उदाहरण प्रदान करती है:

 suspend fun CoroutineScope.doSomeWork(){} GlobalScope.launch{ launch{ delay(100) doSomeWork() } } 

यहाँ, doSomeWork एक संदर्भ फ़ंक्शन है, लेकिन इसके संदर्भ के बाहर परिभाषित किया गया है। लॉन्च विधियां दो नेस्टेड संदर्भ बनाती हैं जो संबंधित कार्यों के शाब्दिक क्षेत्रों के बराबर होती हैं (इस मामले में, दोनों संदर्भ एक ही प्रकार के होते हैं, इसलिए आंतरिक संदर्भ बाहरी को अस्पष्ट करता है)। Kotlin coroutines सीखने के लिए एक अच्छा प्रारंभिक बिंदु आधिकारिक मार्गदर्शिका है।

डीएसएल

कोटलिन के लिए कार्यों की एक विस्तृत श्रेणी है, जिन्हें आमतौर पर डीएसएल (डोमेन विशिष्ट भाषा) के निर्माण के कार्यों के रूप में संदर्भित किया जाता है। इस मामले में, DSL को कुछ कोड के रूप में समझा जाता है जो किसी प्रकार की जटिल संरचना के उपयोगकर्ता के अनुकूल बिल्डर प्रदान करता है। वास्तव में, DSL शब्द का उपयोग पूरी तरह से यहाँ ठीक नहीं है, जैसा कि ऐसे मामलों में, मूल कोटलिन सिंटैक्स का उपयोग बिना किसी विशेष चाल के किया जाता है - लेकिन फिर भी इस सामान्य शब्द का उपयोग करते हैं।

अधिकांश मामलों में DSL बिल्डरों को संदर्भ-उन्मुख किया जाता है। उदाहरण के लिए, यदि आप एक HTML तत्व बनाना चाहते हैं, तो आपको सबसे पहले यह जाँचने की आवश्यकता है कि क्या इस विशेष तत्व को इस स्थान पर जोड़ा जा सकता है। Kotlinx.html पुस्तकालय संदर्भ-आधारित वर्ग एक्सटेंशन प्रदान करके ऐसा करता है जो एक विशिष्ट टैग का प्रतिनिधित्व करता है। वास्तव में, पूरे पुस्तकालय में मौजूदा DOM तत्वों के लिए संदर्भ एक्सटेंशन शामिल हैं।

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

 override val root = gridPane{ tabpane { gridpaneConstraints { vhGrow = Priority.ALWAYS } tab("Report", HBox()) { label("Report goes here") } tab("Data", GridPane()) { tableview<Person> { items = persons column("ID", Person::idProperty) column("Name", Person::nameProperty) column("Birthday", Person::birthdayProperty) column("Age", Person::ageProperty).cellFormat { if (it < 18) { style = "-fx-background-color:#8b0000; -fx-text-fill:white" text = it.toString() } else { text = it.toString() } } } } } } 

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

आगे क्या है: एकाधिक प्राप्तकर्ता

संदर्भ-उन्मुख प्रोग्रामिंग कोटलिन डेवलपर्स को कई उपकरण देता है और एप्लिकेशन आर्किटेक्चर को डिजाइन करने का एक नया तरीका खोलता है। क्या हमें कुछ और चाहिए? शायद हाँ।

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

इसके अलावा

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

मूल लेख के लेखक: एलेक्जेंडर नोज़िक , जेटब्रेन रिसर्च में परमाणु भौतिकी प्रायोगिक प्रयोगशालाओं के उप प्रमुख।

इसके द्वारा अनुवादित: पेट्र क्लीम , न्यूक्लियर फिजिक्स की प्रयोगशाला में शोधकर्ता जेटब्रेन अनुसंधान में