C # में मेटाक्लासेस के विषय पर कल्पनाएँ

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

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

मेटाक्लास क्या है?

तो एक मेटाक्लस क्या है? यह एक विशेष प्रकार है जो अन्य प्रकारों का वर्णन करने के लिए कार्य करता है। C # में बहुत कुछ समान है - टाइप टाइप। लेकिन केवल समान। प्रकार का एक मान किसी भी प्रकार का वर्णन कर सकता है, एक मेटाक्लस केवल वर्ग के वारिसों का वर्णन कर सकता है जब मेटाक्लस घोषित किया गया था।

ऐसा करने के लिए, C का हमारा काल्पनिक संस्करण टाइप <T> टाइप करता है, जो टाइप का उत्तराधिकारी है। लेकिन टाइप <टी> केवल टाइप टी या उसके वंशज का वर्णन करने के लिए उपयुक्त है।
मैं इसे एक उदाहरण से समझाऊंगा:

class A { } class A2 : A { } class B { } static class Program { static void Main() { Type<A> ta; ta = typeof(A); //   ta = typeof(A2); //    ta = typeof(B); //   – Type<B>   Type<A> ta = (Type<A>)typeof(B); //      -   Type tx = typeof(A); ta = tx; //   –    Type  Type<A> ta = (Type<A>)tx; //    Type<B> tb = (Type<B>)tx; //  } } 

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

मेटाक्लास और स्थिर वर्ग के सदस्य

यदि कुछ कक्षा X में स्थिर सदस्य हैं, तो मेटाक्लस प्रकार <X> के सदस्यों को इसके समान मिलता है, अब स्थिर नहीं है, जिसके माध्यम से आप X के स्थैतिक सदस्यों तक पहुंच सकते हैं। आइए इस भ्रमित वाक्यांश को एक उदाहरण के साथ समझाते हैं।

 class X { public static void DoSomething() { } } static class Program { static void Main() { Type<X> tx = typeof(X); tx.DoSomething(); //   ,     X.DoSomething(); } } 

यहां, आम तौर पर बोलते हुए, सवाल उठता है - क्या होगा यदि दसवीं कक्षा में एक स्थिर विधि घोषित की जाती है, तो नाम और पैरामीटर सेट किस प्रकार के वर्ग के तरीकों में से एक के नाम और पैरामीटर सेट के साथ मेल खाता है, जिसका वारिस टाइप <X> है? इस समस्या को हल करने के लिए कई सरल विकल्प हैं, लेकिन मैं उन पर ध्यान नहीं दूंगा - सादगी के लिए हम मानते हैं कि संघर्षों की हमारी फंतासी भाषा में कोई जादू के नाम नहीं हैं।

किसी भी सामान्य व्यक्ति के लिए ऊपर दिया गया कोड भयावह होना चाहिए - अगर हमें इस पद्धति को सीधे कॉल किया जा सकता है तो हमें कॉल करने के लिए चर की आवश्यकता क्यों है? दरअसल, इस रूप में, यह अवसर बेकार है। लेकिन फायदा तब होता है जब आप इसमें क्लास के तरीके जोड़ते हैं।

कक्षा के तरीके

क्लास के तरीके एक और निर्माण है जो डेल्फी के पास है, लेकिन सी # में गायब है। जब घोषित किया जाता है, तो इन विधियों को शब्द वर्ग के साथ चिह्नित किया जाता है और स्थिर तरीकों और उदाहरण विधियों के बीच एक क्रॉस होता है। स्थैतिक तरीकों की तरह, वे एक विशिष्ट उदाहरण के लिए बाध्य नहीं हैं और एक उदाहरण बनाए बिना वर्ग नाम के माध्यम से कहा जा सकता है। लेकिन, स्थैतिक तरीकों के विपरीत, उनके पास एक अंतर्निहित पैरामीटर है। केवल इस मामले में यह वर्ग का एक उदाहरण नहीं है, बल्कि एक मेटाक्लस है, अर्थात। यदि कक्षा X में वर्ग विधि का वर्णन किया गया है, तो इसका यह पैरामीटर टाइप <X> होगा। और आप इसे इस तरह से उपयोग कर सकते हैं:

 class X { public class void Report() { Console.WriteLine($”    {this.Name}”); } } class Y : X { } static class Program { static void Main() { X.Report() // : «    X» Y.Report() // : «    Y» } } 

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

 class X { protected static virtual DoReport() { Console.WriteLine(“!”); } public static Report() { DoReport(); } } class Y : X { protected static override DoReport() { Consloe.WriteLine(“!”); } } static class Program { static void Main() { X.Report() // : «!» Y.Report() // : ??? } } 

Y.Report को कॉल करते समय चीजों के तर्क से, "बाय!" प्रदर्शित होना चाहिए। लेकिन X.Report विधि के बारे में कोई जानकारी नहीं है कि इसे किस वर्ग से बुलाया गया था, इसलिए यह गतिशील रूप से X.DoReport और Y.DoReport के बीच चयन नहीं कर सकता है। नतीजतन, X.Report हमेशा X.DoReport को कॉल करेगा, भले ही रिपोर्ट को Y के माध्यम से बुलाया गया था। DoReport विधि को आभासी बनाने में कोई समझदारी नहीं है। इसलिए, C # स्थिर तरीकों को आभासी बनाने की अनुमति नहीं देता है - यह उन्हें आभासी बनाने के लिए संभव होगा, लेकिन आप उनकी आभासीता से लाभ नहीं ले पाएंगे।

एक और बात क्लास के तरीके हैं। यदि पिछले उदाहरण में रिपोर्ट स्थिर नहीं थी, लेकिन क्लास थी, तो यह "पता" होगा जब इसे एक्स के माध्यम से बुलाया गया था, और जब वाई के माध्यम से। तदनुसार, संकलक कोड उत्पन्न कर सकता है जो वांछित DoReport का चयन करेगा, और Y.Report को कॉल करेगा। निष्कर्ष "बाय!"।

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

 class X { public static virtual Report() { Console.WriteLine(“!”); } } class Y : X { public static override Report() { Consloe.WriteLine(“!”); } } static class Program { static void Main() { Type<X> tx = typeof(X); tx.Report() // : «!» tx = typeof(Y); tx.Report() // : «!» } } 

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

वर्चुअल कंस्ट्रक्टर

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

 class A { public virtual A(int x, int y) { ... } } class B : A { public override B(int x, int y) : base(x, y) { } } class C : A { public C(int z) { ... } } 

इस कोड में, क्लास C को संकलित नहीं किया जाना चाहिए, क्योंकि इसमें एक पैरामीटर नहीं है जिसमें int x, int y, लेकिन class B त्रुटियों के बिना संकलित है।

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

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

 class A { public virtual A(int x, int y) { ... } } class B : A { public override B(int x, int y) : base(x, y) { } } static class Program { static void Main() { Type<A> ta = typeof(A); A a1 = ta.CreateInstance(10, 12); //    A ta = typeof(B); A a2 = ta.CreateInstance(2, 7); //    B } } 

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

निष्कर्ष

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