मैं सुनना चाहता हूँ कि .Net ढांचे में सील वर्गों के थोक के पीछे प्रेरणा क्या है। किसी वर्ग को सील करने से क्या लाभ है? मैं इस बात की थाह नहीं लगा सकता कि वंशानुक्रम की अनुमति देना कैसे उपयोगी हो सकता है और सबसे अधिक संभावना है कि इन वर्गों से लड़ने वाला ही नहीं।
तो, इस तरह से रूपरेखा क्यों बनाई गई है और क्या यह सब कुछ को बदलने के लिए असहनीय परिवर्तन नहीं होगा? एक और कारण होना चाहिए लेकिन सिर्फ बुराई है?
जवाबों:
इस विषय के लिए MSDN आलेख सीलिंग क्लासेस द्वारा विस्तार क्षमता सीमित है ।
कक्षाएं या तो वंशानुक्रम के लिए डिज़ाइन की जानी चाहिए या इसे प्रतिबंधित करना चाहिए। विरासत के लिए डिजाइन करने की लागत है:
प्रभावी जावा का आइटम 17 इस पर अधिक विवरण में जाता है - इस तथ्य के बावजूद कि यह जावा के संदर्भ में लिखा गया है, यह सलाह .NET के साथ भी लागू होती है।
व्यक्तिगत रूप से मेरी इच्छा है कि .NET में डिफ़ॉल्ट रूप से कक्षाएं सील की गईं।
ऐसा लगता है कि सीलिंग पर आधिकारिक Microsoft दिशानिर्देश इस प्रश्न के ~ 9 साल पहले पूछे जाने के बाद विकसित हुए हैं, और वे ऑप्ट-इन दर्शन (डिफ़ॉल्ट रूप से सील) से ऑप्ट-आउट करने के लिए चले गए (डिफ़ॉल्ट रूप से सील न करें):
X ऐसा करने का एक अच्छा कारण के बिना कक्षाओं को सील न करें।
एक वर्ग को सील करना क्योंकि आप एक एक्स्टेंसिबिलिटी परिदृश्य के बारे में नहीं सोच सकते हैं एक अच्छा कारण नहीं है। फ्रेमवर्क उपयोगकर्ता विभिन्न गैर-स्पष्ट कारणों के लिए कक्षाओं से विरासत में लेना पसंद करते हैं, जैसे सुविधा सदस्यों को जोड़ना। गैर-स्पष्ट कारणों के उदाहरणों के लिए अवांछित कक्षाएं देखें जिन्हें उपयोगकर्ता एक प्रकार से प्राप्त करना चाहते हैं।
कक्षा को सील करने के अच्छे कारणों में निम्नलिखित शामिल हैं:
- वर्ग एक स्थिर वर्ग है। स्टैटिक क्लास डिजाइन देखें।
- वर्ग विरासत में सुरक्षित संरक्षित सदस्यों में सुरक्षा-संवेदनशील रहस्यों को संग्रहीत करता है।
- वर्ग कई आभासी सदस्यों को विरासत में मिला है और उन्हें व्यक्तिगत रूप से सील करने की लागत ने वर्ग को छोड़ने के लाभों को आगे बढ़ाया है।
- वर्ग एक विशेषता है जिसे बहुत तेज़ रनटाइम लुक-अप की आवश्यकता होती है। सील विशेषताओं में अनसाल्ड की तुलना में थोड़ा अधिक प्रदर्शन स्तर होता है। विशेषताएँ देखें।
X मुहरबंद प्रकारों पर संरक्षित या आभासी सदस्यों की घोषणा न करें ।
परिभाषा के अनुसार, सील किए गए प्रकारों को विरासत में नहीं दिया जा सकता है। इसका मतलब यह है कि सील किए गए प्रकारों पर संरक्षित सदस्यों को नहीं बुलाया जा सकता है, और सील किए गए प्रकारों पर आभासी तरीकों को ओवरराइड नहीं किया जा सकता है।
✓ CONSIDER सील करने वाले सदस्य जिन्हें आप ओवरराइड करते हैं। वर्चुअल सदस्यों (वर्चुअल सदस्यों में चर्चा किए गए) को शुरू करने के परिणामस्वरूप होने वाली समस्याएं ओवरराइड्स पर लागू होती हैं, हालांकि कुछ हद तक कम। एक ओवरराइड सील करने से आपको इन समस्याओं से विरासत में पदानुक्रम की शुरुआत होती है।
वास्तव में, यदि आप ASP.Net कोर कोडबेस को खोजते हैं , तो आप केवल 30 घटनाओं के बारे में पाएंगे sealed class, जिनमें से अधिकांश विशेषताएँ और परीक्षण कक्षाएं हैं।
मुझे लगता है कि सीलिंग के पक्ष में अपरिवर्तनीय संरक्षण एक अच्छा तर्क है।
मुझे यह वाक्य msdn प्रलेखन में मिला: "सील करने के लिए मुख्य रूप से सील वर्गों का उपयोग किया जाता है। क्योंकि उनका उपयोग आधार वर्ग के रूप में कभी नहीं किया जा सकता है, कुछ रन-टाइम अनुकूलन सीलिंग वर्ग के सदस्यों को थोड़ी तेजी से बुला सकते हैं।"
मुझे नहीं पता कि प्रदर्शन सील वर्गों का एकमात्र लाभ है और व्यक्तिगत रूप से मैं भी किसी अन्य कारणों को जानना चाहूंगा ...
उदाहरण के लिए प्रदर्शन एक महत्वपूर्ण कारक है, जावा में स्ट्रिंग वर्ग अंतिम है (<- सील) और इसका कारण केवल प्रदर्शन है। मुझे लगता है कि एक और महत्वपूर्ण बिंदु विस्तार से वर्णित भंगुर आधार वर्ग की समस्या से बचने के लिए है: http://blogs.msdn.com/ericlippert/archive/2004/01/07/virtual-methods-and-brittle-base-classes। aspx
यदि आप एक ढांचा प्रदान करते हैं तो यह स्थिरता विरासत परियोजनाओं के लिए महत्वपूर्ण है और भंगुर आधार वर्ग की समस्या से बचने के लिए अपने ढांचे को उन्नत करना है
Stringवर्ग उप-वर्ग के लिए भी संभव नहीं हो सकता है, भले ही वह अंतिम न हो।
सीलिंग आपको कुछ मामूली प्रदर्शन लाभ का एहसास करने की अनुमति देता है। C ++ के अनुसार, JITs और आलसी निराशा की दुनिया में यह कम सच है, लेकिन .NET के बाद से pessimization उतना अच्छा नहीं है क्योंकि जावा कंपाइलर ज्यादातर अलग-अलग डिज़ाइन दर्शन के कारण होते हैं, यह अभी भी उपयोगी है। यह संकलक को बताता है कि यह प्रत्यक्ष रूप से किसी भी आभासी तरीकों को कॉल कर सकता है बजाय उन्हें अप्रत्यक्ष रूप से वाइबल के माध्यम से कॉल कर सकता है।
यह भी महत्वपूर्ण है जब आप समानता की तुलना जैसी चीजों के लिए 'बंद दुनिया' चाहते हैं। आम तौर पर एक बार जब मैं एक आभासी विधि को परिभाषित करता हूं, तो मैं समानता की तुलना की धारणा को परिभाषित करने के लिए बहुत अधिक चंगा हूं जो वास्तव में विचार को लागू करता है। दूसरी ओर, मैं इसे आभासी पद्धति के साथ वर्ग के किसी विशेष उपवर्ग के लिए परिभाषित करने में सक्षम हो सकता हूं। उस वर्ग को सील करना सुनिश्चित करता है कि समानता वास्तव में पकड़ में है।
यह निर्धारित करने के लिए कि किसी वर्ग, विधि, या संपत्ति को सील करना है या नहीं, आपको आम तौर पर निम्नलिखित दो बिंदुओं पर विचार करना चाहिए:
• आपके वर्ग को अनुकूलित करने की क्षमता के माध्यम से प्राप्त होने वाले संभावित लाभ लाभ प्राप्त कर सकते हैं।
• कक्षाएं लेने की क्षमता आपकी कक्षाओं को इस तरह से संशोधित कर सकती है कि वे अब सही तरीके से या अपेक्षित रूप से काम नहीं करेंगे।
एक और विचार यह है कि सील किए गए वर्गों को आपकी इकाई परीक्षणों में नहीं लगाया जा सकता है। से माइक्रोसॉफ्ट के प्रलेखन :
सीलबंद कक्षाएं या स्टैटिक मेथड स्टब नहीं किए जा सकते क्योंकि स्टब टाइप वर्चुअल मेथड डिस्पैच पर निर्भर करते हैं। ऐसे मामलों के लिए, यूनिट परीक्षण के लिए अन्य विधानसभाओं से अपने आवेदन को अलग करने के लिए शिम का उपयोग करते हुए वर्णित प्रकार का उपयोग करें