आपको कक्षा को उप-वर्ग से क्यों रोकना चाहिए?

Question

कक्षा को विरासत में रखने से रोकने के कारण क्या हो सकते हैं? (उदाहरण के लिए सी # कक्षा पर मुहरबंद का उपयोग करना) अभी मैं किसी के बारे में नहीं सोच सकता।

Answer 1

अगर आप अभी तक इंटरफ़ेस के बारे में निश्चित नहीं हैं और वर्तमान इंटरफ़ेस के आधार पर कोई अन्य कोड नहीं चाहते हैं तो कैसे? [कि मेरे सिर के ऊपर से है, लेकिन मैं के रूप में अच्छी अन्य कारणों में रुचि होगी!]

संपादित करें: http://codebetter.com/blogs/patricksmacchia/archive/2008/01/05/rambling-on-the-sealed-keyword.aspx

का हवाला देते हुए:

वहाँ googling के एक बिट निम्नलिखित दिया तीन कारण हैं एक सील वर्ग एक सील न की गयी वर्ग की तुलना में बेहतर है:

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

Answer 2

क्योंकि लेखन कक्षाओं substitutably बढ़ाया जा रहा है बहुत कठिन और आपको सटीक भविष्यवाणियां करने की आवश्यकता है कि भविष्य के उपयोगकर्ता आपके द्वारा लिखे गए विस्तार को कैसे विस्तारित करना चाहते हैं।

अपनी कक्षा को सील करने से उन्हें संरचना का उपयोग करने के लिए मजबूर किया जाता है, जो कि अधिक मजबूत है।

Answer 3

यह आपके कोड पर लागू नहीं हो सकता है, लेकिन .NET ढांचे के भीतर बहुत से वर्ग जानबूझकर बंद कर दिए गए हैं ताकि कोई भी उप-वर्ग बनाने की कोशिश न करे।

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

Answer 4

क्योंकि आप हमेशा कक्षा के संदर्भ को सौंपना चाहते हैं, न कि विभिन्न कारणों से व्युत्पन्न व्यक्ति को:
i। आपके कोड
ii के किसी अन्य भाग में आपके पास आविष्कार हैं Ii। सुरक्षा
आदि

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

या शायद आपके पास इंटरफ़ेस का परीक्षण करने के लिए पर्याप्त समय नहीं था कि कक्षा यह सुनिश्चित करने के लिए खुलासा करती है कि आप दूसरों को इससे प्राप्त करने की अनुमति दे सकते हैं।

या शायद सबक्लास होने में कोई बिंदु नहीं है (जिसे आप अब देखते हैं)।

या जब आप उप-वर्ग की कोशिश करते हैं और सभी नट-किरकिरा विवरण प्राप्त करने का प्रबंधन नहीं करते हैं तो आप बग रिपोर्ट नहीं चाहते हैं - समर्थन लागत में कटौती करें।

Answer 5

@jjnguy

अन्य उपयोगकर्ता अपने वर्ग उप classing द्वारा अपने कोड का फिर से उपयोग कर सकते हैं। मुझे इसे रोकने का कोई कारण नहीं दिख रहा है।

यदि वे मेरी कक्षा की कार्यक्षमता का उपयोग करना चाहते हैं तो वे इसे रोकथाम के साथ प्राप्त कर सकते हैं, और परिणामस्वरूप उनके पास बहुत कम भंगुर कोड होगा।

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

Answer 6

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

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

Answer 7

मैं "कोड पूर्ण" से आप इस संदेश देना चाहता हूँ: - उपवर्गों -

विरासत प्राथमिक तकनीकी जरूरी आप एक प्रोग्रामर, जटिलता का प्रबंधन करने के लिए है जो के रूप में है के खिलाफ काम करता है। जटिलता को नियंत्रित करने के लिए, आपको विरासत के खिलाफ भारी पूर्वाग्रह बनाए रखना चाहिए।

Answer 8

मैं jjnguy के साथ समझौता कर रहा हूं ... मुझे लगता है कि कक्षा को सील करने के कारण कुछ और बहुत दूर हैं। इसके विपरीत, मैं एक बार से अधिक परिस्थितियों में रहा हूं जहां मैं कक्षा का विस्तार करना चाहता हूं, लेकिन ऐसा नहीं कर सका क्योंकि यह बंद कर दिया गया था।

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

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

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

यह एक कारण है कि मुझे वास्तव में रूबी प्रोग्रामिंग भाषा पसंद है ... यहां तक ​​कि कोर कक्षाएं भी खुली हैं, न केवल विस्तार करने के लिए बल्कि गतिशील रूप से कार्यक्षमता को बदलने और बदलने के लिए, क्लास को स्वयं! इसे बंदरगाह कहा जाता है और अगर दुर्व्यवहार किया जाता है तो दुःस्वप्न हो सकता है, लेकिन यह खेलने के लिए बहुत मजेदार है!

Answer 9

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

Answer 10

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

ठीक है, एक कारण है: आपका कोड अब कुछ हद तक memcached इंटरफ़ेस में इन्सुलेट किया गया है।

Answer 11

प्रदर्शन:। (...) यदि JIT कम्पाइलर एक सील प्रकार का उपयोग कर एक आभासी विधि के लिए एक कॉल को देखता है, JIT कम्पाइलर और अधिक कुशल कोड विधि बुला गैर लगभग द्वारा उत्पादन कर सकते हैं (...)

यह वास्तव में एक शानदार कारण है। इस प्रकार, प्रदर्शन-महत्वपूर्ण कक्षाओं के लिए, sealed और दोस्तों को समझ में आता है।

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

Answer 12

विरासत का एकमात्र वैध उपयोग आधार वर्ग के किसी विशेष मामले को परिभाषित करना है, उदाहरण के लिए, जब आकार से प्राप्त चक्र से प्राप्त होता है। विपरीत दिशा में संबंध को देखने के लिए: क्या आकार सर्किल का सामान्यीकरण है? अगर उत्तर हाँ है तो विरासत का उपयोग करना ठीक है।

तो यदि आपके पास ऐसी कक्षा है जिसके लिए कोई विशेष मामला नहीं हो सकता है जो उसके व्यवहार को विशेषज्ञ बनाता है तो इसे बंद कर दिया जाना चाहिए।

इसके अलावा LSP (Liskov प्रतिस्थापन सिद्धांत) के कारण

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

एक और ठोस उदाहरण सिंगलटन पैटर्न होगा। यह सुनिश्चित करने के लिए कि आप "सिंगलोननेस" तोड़ नहीं सकते हैं, आपको सिंगलटन को सील करने की आवश्यकता है।

Answer 13

किसी ऑब्जेक्ट-ओरिएंटेड परिप्रेक्ष्य से, एक वर्ग को सील करने से टिप्पणियों की आवश्यकता के बिना लेखक के इरादे को स्पष्ट रूप से दस्तावेज किया जाता है। जब मैं एक वर्ग को सील करता हूं तो मैं यह कहने की कोशिश कर रहा हूं कि इस वर्ग को ज्ञान के कुछ विशिष्ट टुकड़े या कुछ विशिष्ट सेवा को समाहित करने के लिए डिज़ाइन किया गया था। यह आगे बढ़ने या उपclassed करने के लिए नहीं था।

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

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

इन सबक्लासों को सील करना भी विरासत के गहरे स्तर को हतोत्साहित करता है, जो जीयूआई ढांचे के लिए अच्छी तरह से काम करता है लेकिन व्यवसाय तर्क परतों के लिए खराब काम करता है।

Answer 14

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

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

बहुत ठोस वस्तुओं से शुरू होने पर, मुझे विशेषताओं और [इस प्रकार] कार्यक्षमता मिलती है जो उनके समान हैं और मैं इसे उन विशेष वस्तुओं के सुपरक्लस के लिए सारणित करता हूं। यह कोड डुप्लिकेट को कम करने का एक तरीका है।

कुछ विशिष्ट उत्पाद जैसे ढांचे के विकास के बिना, मुझे मेरा कोड, अन्य (वर्चुअल) कोड नहीं चाहिए। तथ्य यह है कि दूसरों को मेरे कोड का पुन: उपयोग करने में उपयोगी लग सकता है, यह मेरा अच्छा लक्ष्य नहीं है, अच्छा बोनस है। यदि वे ऐसा करने का निर्णय लेते हैं, तो एक्सटेंशन की वैधता सुनिश्चित करना उनकी ज़िम्मेदारी है। यह टीम-व्यापी लागू होता है। उत्पादकता के लिए ऊपर की ओर डिजाइन महत्वपूर्ण है।

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

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

लोग अक्सर डरते हैं कि उनके "खुले" वर्गों को उस चीज पर मोड़ दिया जाएगा जो इसके ascendants को प्रतिस्थापित नहीं कर सकता है। तो क्या? आपको परवाह क्यों करनी चाहिए? कोई प्रोग्राम खराब प्रोग्रामर को खराब सॉफ़्टवेयर बनाने से रोक सकता है!

मैं विरासत योग्य कक्षाओं को डिजाइन करने के आखिरकार सही तरीके के रूप में इंगित करने की कोशिश नहीं कर रहा हूं, इस पर विचार करें कि विरासत योग्य वर्गों के प्रति मेरी झुकाव की व्याख्या की तरह। यह प्रोग्रामिंग की सुंदरता है - सही समाधानों का असीमित सेट, प्रत्येक अपने स्वयं के विपक्ष और पेशेवरों के साथ। आपकी टिप्पणियां और तर्क स्वागत है।

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