.NET फ्रेमवर्क में प्रथम श्रेणी के प्रकारों की कोई अवधारणा क्यों नहीं है?

Question

यह इतिहास से परिचित लोगों के लिए अच्छी तरह से ज्ञात है कि C # और .NET फ्रेमवर्क अनिवार्य रूप से शुरू हुआ "डेल्फी को जावा की तरह महसूस करने के लिए फिर से लिखा," डेल्फी, एंडर्स हेजेल्सबर्ग के पीछे मुख्य डेवलपर द्वारा आर्किटेक्चर किया गया। तब से चीजें काफी बदल गई हैं, लेकिन जल्दी ही समानताएं इतनी स्पष्ट थीं कि कुछ गंभीर अटकलें भी थीं कि .NET वास्तव में मूल रूप से बोरलैंड का उत्पाद था।

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

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

.NET में कुछ भी समतुल्य प्रतीत नहीं होता है। वर्ग संदर्भ (और विशेष रूप से वर्चुअल कंस्ट्रक्टर और अन्य वर्चुअल क्लास तरीकों के रूप में) के साथ उपयोगी है, क्या किसी ने इस बारे में कुछ कहा है कि उन्हें क्यों छोड़ दिया गया?

विशिष्ट उदाहरण

रूप का वर्णन

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

object Name: ClassName
   property = value
   property = value
   ...
   object SubObjectName: ClassName
      ...
   end
end

यहाँ दिलचस्प बात यह है कि ClassNameहिस्सा है। प्रत्येक घटक वर्ग समय TClassपर घटक स्ट्रीमिंग सिस्टम के साथ अपना पंजीकरण initializationकरता है (स्टैटिक कंस्ट्रक्टर लगता है, केवल थोड़ा अलग है, स्टार्टअप पर तुरंत होने की गारंटी है।) यह प्रत्येक कक्षा को एक स्ट्रिंग में>> क्लास क्लैम हैशमप की कुंजी के रूप में नाम के साथ पंजीकृत करता है।

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

इसे कम करना, WinForms समतुल्य है ... अच्छी तरह से ... यह एक बड़ी गड़बड़ी है, इसे पूरी तरह से फिर से लागू करने के लिए किसी भी नई .NET भाषा की आवश्यकता है। जब आप इसके बारे में सोचते हैं तो यह थोड़ा चौंकाने वाला होता है; सीएलआर होने के पूरे बिंदु के बाद से कई भाषाओं को एक ही बुनियादी ढांचे का उपयोग करने के लिए है, एक डीएफएम-शैली प्रणाली ने सही अर्थ बनाया होगा।

तानाना

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

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

Comments

शायद इसलिए कि यह उच्च प्राथमिकता वाला फीचर नहीं था जो C # टीम के बजट में फिट होता है ।

— डोभाल

क्या आप एक या दो ठोस उदाहरण प्रदान कर सकते हैं जहां एक TClassउपयोगी है, कुछ नमूना कोड के साथ? के बारे में मेरे सरसरी इंटरनेट अनुसंधान में TClass, मैं पा रहा हूँ कि TClassएक पैरामीटर के रूप में चारों ओर पारित किया जा सकता है। यह Generics का उपयोग करते हुए .NET में किया जाता है। फैक्ट्री के तरीकों को केवल static.NET में चिह्नित किया जाता है, और निष्पादित करने के लिए वर्ग उदाहरण की आवश्यकता नहीं होती है।

— रॉबर्ट हार्वे

@RobertHarvey: मेरे लिए, व्यक्तिगत रूप से, C # ने बहुत अधिक समझदारी शुरू कर दी, जब मैंने इसे जावा / सी ++ के रूप में देखना बंद कर दिया और इसे मॉडुला -2 के रूप में वस्तुओं के साथ व्यवहार करना शुरू कर दिया। यह जावा के साथ समान है: हर कोई कहता है कि यह C ++ से प्रभावित था, लेकिन यह सच नहीं है। इसका मुख्य प्रभाव ऑब्जेक्टिव-सी (और उस के माध्यम से स्मॉलटाक) है, और जीसी के साथ सी ++ के बजाय टाइप के साथ इसे स्मॉलटॉक के रूप में व्यवहार करने पर जावा बहुत अधिक समझ में आएगा ।

— जोर्ग डब्ल्यू मित्तग

@RobertHarvey: TClassएक मौलिक भाषा सुविधा है जिसे कंपाइलर समर्थन की आवश्यकता होती है। आप अपनी भाषा लिखे बिना "अपना खुद का" लिख नहीं सकते हैं, और .NET के लिए भी पर्याप्त नहीं होगा क्योंकि ऑब्जेक्ट मॉडल CLR द्वारा परिभाषित किया गया है, न कि अलग-अलग भाषाओं द्वारा। यह कुछ ऐसा है जो सचमुच .NET फ्रेमवर्क का हिस्सा होना चाहिए, या यह मौजूद नहीं हो सकता।

— मेसन व्हीलर

सबसे पहले, मैं अत्यंत निश्चितता के साथ कह सकता हूं कि .NET मूल रूप से एक "बोरलैंड" उत्पाद नहीं था। मुझे इसके बारे में कैसे पता है? मैं मूल (कोर) टीम का हिस्सा था जिसने डेल्फी को विकसित किया। मैंने एंडर्स, चक, गैरी और अन्य के साथ मिलकर काम किया। बेशक, मुझे यकीन है कि आप यह जानते हैं। .NET संदर्भ के रूप में वर्ग के अस्तित्व के लिए (जैसा कि TClass और इसी तरह के निर्माण कहा जाता है) .NET में अमीर रन-टाइम सुलभ प्रकार की जानकारी के अस्तित्व के कारण अनावश्यक रूप से समझा जाता था। डेल्फी को शुरुआत में बहुत कम टाइप की जानकारी थी और क्लास रेफरी एक समझौता था।

— एलन बाउर

Answer 1

.NET (CLR) Microsoft की घटक वस्तु मॉडल (COM) की तीसरी पीढ़ी थी, जिसे शुरुआती दिनों में "COM + रनटाइम" के रूप में जाना जाता था। Microsoft विज़ुअल बेसिक और COM / ActiveX नियंत्रण बाजार ने बोरलैंड डेल्फी की तुलना में विशिष्ट सीएलआर वास्तुशिल्प संगतता विकल्पों पर बहुत अधिक प्रभाव डाला है। (निश्चित रूप से यह तथ्य कि डेल्फी ने ActiveX नियंत्रणों को अपनाया था, उसने निश्चित रूप से ActiveX पारिस्थितिकी तंत्र को विकसित करने में मदद की, लेकिन COM / ActiveX डेल्फी से पहले मौजूद था)

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

इसलिए COM और ActiveX नियंत्रणों की लोकप्रियता के परिणामस्वरूप, .NET आर्किटेक्चर को COM IUnogn, IClassFactory और ITypeLibrary पर समर्थन के लिए बनाया गया था। COM में, ये इंटरफेस आवश्यक रूप से एक ही ऑब्जेक्ट पर नहीं थे, इसलिए इनका एक साथ लंपिंग करना आवश्यक नहीं था।