📃 🥘 😄 कोटलिन: गहरी खुदाई। कंस्ट्रक्टर और इनिशियलाइज़र 🛐 🕶️ 💆🏿

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

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

आज, कोटलिन पहले से ही कई बचपन की बीमारियों से उबरने में कामयाब रहे, ढेर सारे सवालों और ढेर ओवरफ्लो पर जवाब दिया। नग्न आंखों से, इसके फायदे और कमजोरियां दोनों दिखाई देने लगीं।

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

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

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

class MyClassA

यह निम्नलिखित प्रविष्टि के बराबर है:

 class MyClassA constructor()

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

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

यदि, उदाहरण के लिए, हम चाहते हैं कि प्राथमिक निर्माता बिना मापदंडों के सार्वजनिक पहुंच न हो, तो private संशोधन के साथ हमें constructor कीवर्ड के साथ इसे स्पष्ट रूप से घोषित करना होगा।

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

 class MyClassA constructor(param1: String, param2: Int, param3: Boolean){ // some code }

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

 class MyClassA constructor(val param1: String, var param2: Int, param3: Boolean){ // some code }

यहां, param1 और param2 को कोड के रूप में उपयोग किया जा सकता है, जो कि कक्षा के क्षेत्र के रूप में है, जो निम्न के बराबर है:

 class MyClassA constructor(p1: String, p2: Int, param3: Boolean){ val param1 = p1 var param2 = p2 // some code }

खैर, यदि आप जावा के साथ तुलना करते हैं, तो यह इस तरह दिखाई देगा (और वैसे, इस उदाहरण में आप मूल्यांकन कर सकते हैं कि कोटलिन कोड की मात्रा को कितना कम कर सकता है):

 public class MyClassAJava { private final String param1; private Integer param2; public MyClassAJava(String p1, Integer p2, Boolean param3) { this.param1 = p1; this.param2 = p2; } public String getParam1() { return param1; } public Integer getParam2() { return param2; } public void setParam2(final Integer param2) { this.param2 = param2; } // some code }

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

 class MyClassA(val p1: String) { constructor(p1: String, p2: Int, p3: Boolean) : this(p1) { // some code } // some code }

यानी अतिरिक्त निर्माणकर्ता, जैसा कि यह था, प्राथमिक का उत्तराधिकारी।
अब, यदि हम एक अतिरिक्त कंस्ट्रक्टर को कॉल करके एक ऑब्जेक्ट बनाते हैं, तो निम्न होगा:

अतिरिक्त निर्माता को कॉल करें;
मुख्य निर्माता को बुलाओ;
मुख्य निर्माता में वर्ग p1 1 के एक क्षेत्र का आरंभीकरण;
एक अतिरिक्त कंस्ट्रक्टर के शरीर में कोड निष्पादन।

यह जावा में इस तरह के निर्माण के समान है:

 class MyClassAJava { private final String param1; public MyClassAJava(String p1) { param1 = p1; } public MyClassAJava(String p1, Integer p2, Boolean param3) { this(p1); // some code } // some code }

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

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

 class MyClassA(p1: String) { constructor(p1: String, p2: Int, p3: Boolean) : this(p1) { // some code } constructor(p1: String, p2: Int, p3: Boolean, p4: String) : this(p1, p2, p3) { // some code } // some code }

अब अनुक्रम है:

4 मापदंडों के साथ एक अतिरिक्त निर्माता को कॉल करना;
3 मापदंडों के साथ एक अतिरिक्त निर्माता को कॉल करना;
प्राथमिक निर्माता को बुलाओ;
प्राथमिक कंस्ट्रक्टर में कक्षा पी 1 के एक क्षेत्र का आरंभीकरण;
3 मापदंडों के साथ कंस्ट्रक्टर के शरीर में कोड निष्पादन;
4 मापदंडों के साथ कंस्ट्रक्टर बॉडी में कोड निष्पादन।

किसी भी स्थिति में, कंपाइलर हमें प्राथमिक निर्माणकर्ता को प्राप्त करने की अनुमति नहीं देगा।

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

 class MyClassA { // some code }

हम कॉल करके एक क्लास ऑब्जेक्ट बना सकते हैं:

 val myClassA = MyClassA()

इस मामले में:

 class MyClassA { constructor(p1: String, p2: Int, p3: Boolean) { // some code } // some code }

हम केवल इस कॉल के साथ एक ऑब्जेक्ट बना सकते हैं:

 val myClassA = MyClassA(“some string”, 10, True)

जावा की तुलना में कोटलिन में कुछ भी नया नहीं है।

वैसे, प्राथमिक कंस्ट्रक्टर की तरह, अतिरिक्त कंस्ट्रक्टर के पास बॉडी नहीं हो सकती है यदि उसका कार्य केवल अन्य कंस्ट्रक्टरों को पैरामीटर पास करना है।

 class MyClassA { constructor(p1: String, p2: Int, p3: Boolean) : this(p1, p2, p3, "") constructor(p1: String, p2: Int, p3: Boolean, p4: String) { // some code } // some code }

यह इस तथ्य पर भी ध्यान देने योग्य है कि, प्राथमिक कंस्ट्रक्टर के विपरीत, अतिरिक्त कंस्ट्रक्टर की तर्क सूची में वर्ग फ़ील्ड का आरंभीकरण निषिद्ध है।
यानी ऐसा रिकॉर्ड अमान्य होगा:

 class MyClassA { constructor(val p1: String, var p2: Int, p3: Boolean){ // some code } // some code }

अलग-अलग, यह ध्यान देने योग्य है कि अतिरिक्त निर्माणकर्ता, प्राथमिक एक की तरह, मापदंडों के बिना अच्छी तरह से हो सकता है:

 class MyClassA { constructor(){ // some code } // some code }

कंस्ट्रक्टरों की बात करें तो कोई भी कोटलिन की सुविधाजनक विशेषताओं में से एक का उल्लेख नहीं कर सकता है - तर्क के लिए डिफ़ॉल्ट मान प्रदान करने की क्षमता।

अब मान लीजिए कि हमारे पास कई निर्माणकर्ताओं के साथ एक वर्ग है, जिनके पास अलग-अलग तर्क हैं। मैं जावा में एक उदाहरण दूंगा:

 public class MyClassAJava { private String param1; private Integer param2; private boolean param3; private int param4; public MyClassAJava(String p1) { this (p1, 5); } public MyClassAJava(String p1, Integer p2) { this (p1, p2, true); } public MyClassAJava(String p1, Integer p2, boolean p3) { this(p1, p2, p3, 20); } public MyClassAJava(String p1, Integer p2, boolean p3, int p4) { this.param1 = p1; this.param2 = p2; this.param3 = p3; this.param4 = p4; } // some code }

जैसा कि अभ्यास से पता चलता है, इस तरह के डिजाइन काफी आम हैं। आइए देखें कि कोटलिन पर कैसे लिखा जा सकता है:

 class MyClassA (var p1: String, var p2: Int = 5, var p3: Boolean = true, var p4: Int = 20){ // some code }

अब, कोडिन को एक साथ पैट करें कि उसने कोड को कितना काटा। वैसे, लाइनों की संख्या को कम करने के अलावा, हमें अधिक ऑर्डर मिलते हैं। याद रखें, आपने एक से अधिक बार ऐसा कुछ देखा होगा:

  public MyClassAJava(String p1, Integer p2, boolean p3) { this(p3, p1, p2, 20); } public MyClassAJava(boolean p1, String p2, Integer p3, int p4) { // some code }

जब आप इसे देखते हैं, तो आप उस व्यक्ति को ढूंढना चाहते हैं जिसने इसे लिखा था, एक बटन लें, इसे स्क्रीन पर लाएं और उदास स्वर में पूछें: "क्यों?"
हालांकि आप कोटलिन पर इस उपलब्धि को दोहरा सकते हैं, लेकिन आवश्यक नहीं।

हालाँकि, एक विवरण है कि, कोटलिन पर इस तरह के संक्षिप्त संकेतन के मामले में, यह ध्यान में रखना आवश्यक है: यदि हम जावा से डिफ़ॉल्ट मानों के साथ कंस्ट्रक्टर को कॉल करना चाहते हैं, तो हमें @JvmOverloads एनोटेशन जोड़ना होगा:

 class MyClassA @JvmOverloads constructor(var p1: String, var p2: Int = 5, var p3: Boolean = true, var p4: Int = 20){ // some code }

अन्यथा, हमें एक त्रुटि मिलती है।

अब बात करते हैं इनिशियलाइज़र्स की ।

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

जावा में आरंभीकरण ब्लॉक भी हैं, लेकिन ये एक ही चीज नहीं हैं। उनमें, हम नहीं कर सकते, जैसा कि कोटलिन में, बाहर से एक मूल्य (प्राथमिक निर्माता के तर्क) पास करते हैं। प्रारंभिक एक अलग ब्लॉक में निकाले गए प्रारंभिक कंस्ट्रक्टर के शरीर के समान है। लेकिन यह पहली नजर में है। वास्तव में, यह पूरी तरह से सच नहीं है। चलो ठीक है।

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

मैं आपको शुरुआती के साथ काम करने के कुछ दिलचस्प मामले दूंगा।

 class MyClassB { init { testParam = "some string" showTestParam() } init { testParam = "new string" } var testParam: String = "after" constructor(){ Log.i("wow", "in constructor testParam = $testParam") } fun showTestParam(){ Log.i("wow", "in showTestParam testParam = $testParam") } }

यह कोड काफी मान्य है, हालांकि काफी स्पष्ट नहीं है। यदि आप देखते हैं, तो आप देख सकते हैं कि पैरामीटर घोषित किए जाने से पहले इनिशियलाइज़र ब्लॉक में testParam फ़ील्ड के मान का असाइनमेंट होता है। वैसे, यह केवल तभी काम करता है जब हमारे पास क्लास में एक अतिरिक्त कंस्ट्रक्टर होता है, लेकिन हमारे पास एक प्राथमिक कंस्ट्रक्टर नहीं होता है (यदि हम init ब्लॉक के ऊपर testParam फ़ील्ड की घोषणा को testParam , तो यह बिना कंस्ट्रक्टर के काम करेगा)। यदि हम जावा में इस वर्ग के बाइट कोड को हटाते हैं, तो हमें निम्नलिखित मिलते हैं:

 public class MyClassB { @NotNull private String testParam = "some string"; @NotNull public final String getTestParam() { return this.testParam; } public final void setTestParam(@NotNull String var1) { Intrinsics.checkParameterIsNotNull(var1, "<set-?>"); this.testParam = var1; } public final void showTestParam() { Log.i("wow", "in showTestParam testParam = " + this.testParam); } public MyClassB() { this.showTestParam(); this.testParam = "new string"; this.testParam = "after"; Log.i("wow", "in constructor testParam = " + this.testParam); } }

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

और testParam लिए सबसे दिलचस्प बात: testParam हस्ताक्षर को var से val बदलें:

 class MyClassB { init { testParam = "some string" showTestParam() } init { testParam = "new string" } val testParam: String = "after" constructor(){ Log.i("wow", "in constructor testParam = $testParam") } fun showTestParam(){ Log.i("wow", "in showTestParam testParam = $testParam") } }

और कहीं न कहीं कोड में हम कहते हैं:

 MyClassB myClassB = new MyClassB();

सब कुछ त्रुटियों के बिना संकलित, शुरू, और अब हम लॉग का आउटपुट देखते हैं:

in showTestParam testParam = कुछ तार
in रचनाकार testParam = after

यह पता चला है कि val रूप में घोषित फ़ील्ड को कोड निष्पादन के दौरान मूल्य बदल दिया गया है। ऐसा क्यों? मुझे लगता है कि यह कोटलिन संकलक में एक दोष है, और भविष्य में, शायद यह संकलन नहीं करेगा, लेकिन आज सब कुछ वैसा ही है।

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

So. प्रारंभकर्ता कोड का एक निश्चित ब्लॉक होता है जिसे ऑब्जेक्ट बनाते समय निष्पादित किया जाना चाहिए, चाहे जिस भी कंस्ट्रक्टर से यह ऑब्जेक्ट बनाया गया हो।

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

अतिरिक्त निर्माता को कॉल करें;
प्राथमिक निर्माता को बुलाओ;
कोड में उनके स्थान के क्रम में वर्ग फ़ील्ड और इनिशलाइज़र ब्लॉक का आरंभीकरण;
एक अतिरिक्त कंस्ट्रक्टर के शरीर में कोड निष्पादन।

विरासत वाले मामले अधिक दिलचस्प लगते हैं।

यह ध्यान देने योग्य है कि चूंकि ऑब्जेक्ट जावा में सभी वर्गों के लिए आधार है, इसलिए कोई भी कोटलिन में ऐसा है। हालाँकि, Any और Object एक ही चीज नहीं हैं।

आरंभ करने के लिए कि वंशानुक्रम कैसे काम करता है। मूल वर्ग की तरह वंशज वर्ग में प्राथमिक निर्माता हो सकता है या नहीं भी हो सकता है, लेकिन इसे मूल वर्ग के एक विशिष्ट निर्माता का उल्लेख करना चाहिए।

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

 class MyClassC(p1: String): MyClassA(p1) { constructor(p1: String, p2: Int): this(p1) { //some code } //some code }

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

 class MyClassC : MyClassA { constructor(p1: String): super(p1) { //some code } constructor(p1: String, p2: Int): super(p1, p2) { //some code } //some code }

इसके अलावा, व्युत्पन्न वर्ग के अन्य निर्माणकर्ताओं के माध्यम से मूल कक्षा के निर्माता को अप्रत्यक्ष रूप से कॉल करने की संभावना के बारे में मत भूलना:

 class MyClassC : MyClassA{ constructor(p1: String): super(p1){ //some code } constructor(p1: String, p2: Int): this (p1){ //some code } //some code }

यदि वंशज वर्ग के पास कोई निर्माणकर्ता नहीं है, तो हम बस वंशज वर्ग के नाम के बाद मूल वर्ग के निर्माणकर्ता को जोड़ते हैं:

 class MyClassC: MyClassA(“some string”) { //some code }

हालांकि, अभी भी वंशानुक्रम के साथ एक विकल्प है, जिसमें मूल वर्ग के निर्माता के संदर्भ की आवश्यकता नहीं है। ऐसा रिकॉर्ड मान्य है:

 class MyClassC : MyClassB { constructor(){ //some code } constructor(p1: String){ } //some code }

लेकिन केवल तभी जब मूल श्रेणी में बिना पैरामीटर के एक कंस्ट्रक्टर होता है, जो कि डिफ़ॉल्ट कंस्ट्रक्टर (प्राथमिक या वैकल्पिक - यह महत्वपूर्ण नहीं है)।

अब विरासत के दौरान इनिशियलाइज़र और कंस्ट्रक्टरों के आह्वान के आदेश पर विचार करें:

उत्तराधिकारी के अतिरिक्त निर्माता को बुलाओ;
वारिस के प्राथमिक निर्माता को बुलाओ;
माता-पिता के अतिरिक्त निर्माता को कॉल करना;
माता-पिता के प्राथमिक निर्माता को बुलाओ;
मूल init ब्लॉक init
माता-पिता के अतिरिक्त कंस्ट्रक्टर के शरीर कोड का निष्पादन;
वारिस के init ब्लॉक का निष्पादन;
वारिस के अतिरिक्त कंस्ट्रक्टर के बॉडी कोड का निष्पादन।

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

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

कोटलिन: गहरी खुदाई। कंस्ट्रक्टर और इनिशियलाइज़र

More articles: