व्युत्पन्न कक्षाओं में अतिरिक्त सार्वजनिक तरीकों?

Question

अगर मैं एक अमूर्त वर्ग और उस वर्ग के व्युत्पन्न वर्ग है, कर रहा हूँ मैं जिसे ठीक है, अच्छी और व्यावहारिक डिजाइन अभ्यास के अनुसार, कि व्युत्पन्न वर्ग अतिरिक्त सार्वजनिक तरीकों प्रदान नहीं करना चाहिए (वे केवल सार वर्गों को लागू करने और वैकल्पिक रूप से माता पिता के तरीकों को ओवरराइट)?

इसके अलावा, यह प्रत्येक व्युत्पन्न वर्ग के लिए एक अलग निर्माता विधि हस्ताक्षर करने के लिए स्वीकार्य अभ्यास है?

Answer 1

व्यक्तिगत रूप से, मैं किसी के साथ कोई समस्या नहीं देखते हैं।

व्युत्पन्न वर्ग पर अतिरिक्त सार्वजनिक तरीकों के लिए के रूप में:

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

निर्माता हस्ताक्षर के लिए के रूप में -

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

कहा जा रहा है:

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

Answer 2

यह पूरी तरह से आपके व्युत्पन्न वर्ग के लिए अतिरिक्त सार्वजनिक तरीकों को जोड़ने के लिए स्वीकार्य है। उन्हें विभिन्न रचनाकारों को देने के लिए भी पूरी तरह से स्वीकार्य है। (वास्तव में, यह काफी आम है।)

Answer 3

व्युत्पन्न वर्ग अतिरिक्त सार्वजनिक तरीकों

एक कुत्ता कर सकते हैं कि एक पशु नहीं कर सकते हैं प्रदान नहीं करना चाहिए?

इसके अलावा, क्या यह प्रत्येक व्युत्पन्न कक्षा के लिए एक अलग कन्स्ट्रक्टर विधि हस्ताक्षर करने के लिए स्वीकार्य अभ्यास है?

कोई समस्या यहां है। व्युत्पन्न प्रकारों को उनके भाई बहनों या माता-पिता के कन्स्ट्रक्टर हस्ताक्षर से मेल खाने की आवश्यकता नहीं है।

Answer 4

यह व्युत्पन्न कक्षाओं की सुंदरता है।

जबकि पेन श्रेणी में एक लेखन() फ़ंक्शन हो सकता है, एक रिट्रैक्टेबलपेन क्लास जो पेन को विस्तारित करता है, में एक retractPoint() फ़ंक्शन भी हो सकता है।

जब आप एक वर्ग इसका मतलब है का विस्तार - सचमुच - यह की कार्यक्षमता बढ़ाने।

Answer 5

नहीं, यह अतिरिक्त सार्वजनिक तरीकों को जोड़ने के लिए पूरी तरह से उचित (और कभी-कभी डिजाइन द्वारा बहुत जरूरी) है। (पूरी तरह से काल्पनिक) एक Shape सार आधार वर्ग एक Location सदस्य और एक Size विधि है की स्थिति पर विचार करें। जब आप Shape से Polygon निकाले जाते हैं, उदाहरण के लिए, अगर आप किसी सार्वजनिक विधि GetNumberOfSides() बुलाया जोड़ने के लिए उदाहरण के लिए चाहते हो सकता है; लेकिन जब आप CircleShape से प्राप्त करते हैं तो आप यह नहीं चाहते हैं।

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

Answer 6

यह सामान्य रूप में ठीक है।

क्या आप से बचने के लिए सामान्य में विशिष्ट उपयोग कर रहा है चाहता हूँ। यानी

foreach(Animal a in myFarm.Animals) 
{ 
    a.Feed(); 
    // this is a bit grim 
    if(a is Horse) 
    { 
     ((Horse)a).CleanStable(); 
    } 
} 

तो यह सार्वजनिक विधि जोड़ने का कार्य नहीं है बल्कि आप उन्हें कहां से कॉल करते हैं।

Answer 7

यह केवल स्वीकार्य नहीं है, अक्सर रचनाकारों के लिए अलग होना आवश्यक है। उदाहरण के लिए, अगर हम एक (अपरिवर्तनीय) Rectangle वर्ग है और साथ यह विस्तार एक (अपरिवर्तनीय) Square, स्क्वायर के निर्माता (पल के लिए जावा का उपयोग करने के) होना चाहिए

public Square(double size) 

Rectangle के निर्माता हो जाएगा, जबकि

public Rectangle(double width, double height) 

क्या होने की आवश्यकता है कि सबक्लास निर्माता को कुछ उपयुक्त सुपरक्लास कन्स्ट्रक्टर को कॉल करना चाहिए।

अतिरिक्त सार्वजनिक तरीकों के रूप में, यह उपयोग पर निर्भर हो सकता है। स्क्वायर मामले के लिए, मैं कोई अतिरिक्त विधि नहीं जोड़ूंगा। जावा में, हालांकि, Writer का उप-वर्ग PrintWriter है जिसका उद्देश्य कुछ सुविधा विधियों को जोड़ना है। इस मामले में मुझे लगता है कि यह ठीक है (जावा निश्चित रूप से कुछ बुरे उदाहरण हैं लेकिन मुझे नहीं लगता कि यह उनमें से एक है)। मैं कंटेनर/उप-प्रकार के प्रकारों के लिए कुछ अतिरिक्त तरीकों की संभावना की भी अपेक्षा करता हूं।

आपको क्या करना नहीं चाहिए सुपर क्लास विधियों को इस तरह से बदलना चाहिए कि सुपर क्लास की अपेक्षाओं का उल्लंघन हो।

Answer 8

यदि आप Liskov substitution principle का सम्मान करते हैं, तो आप जो भी चाहते हैं वह कर सकते हैं।

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